Re: sblock state on FreeBSD 6.1

From: "Larry Rosenman" <lrosenman(at)pervasive(dot)com>
To: "Jim Nasby" <jnasby(at)pervasive(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sblock state on FreeBSD 6.1
Date: 2006-05-03 18:15:59
Message-ID: F6616E0E81AC0841B1F9DD252F7C4B55041A58@ausmaildd.aus.pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim C. Nasby wrote:
> On Wed, May 03, 2006 at 01:37:03PM -0400, Tom Lane wrote:
>> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
>>> On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
>>>> Actually, the stats socket seems like a really good bet to me,
>>>> since all the backends will be interested in the same socket. The
>>>> client-to-backend sockets are only touched by two processes each,
>>>> so don't seem like big contention sources.
>>
>>> Do we take specific steps to ensure that we don't block when
>>> attempting to write to these sockets?
>>
>> Well, we have the socket set to O_NONBLOCK mode. Whether that avoids
>> the problem you're seeing ...
>
> A quick grep through the source code doesn't look too promising, so
> maybe that's not the proper way not to block on FBSD. Though Larry was
> telling me that there's recently been changes made in the socket code,
> so maybe this problem was fixed recently.

I didn't see a direct hit looking at the routines we talked about
yesterday, but
I can't be sure.

--
Larry Rosenman
Database Support Engineer

PERVASIVE SOFTWARE. INC.
12365B RIATA TRACE PKWY
3015
AUSTIN TX 78727-6531

Tel: 512.231.6173
Fax: 512.231.6597
Email: Larry(dot)Rosenman(at)pervasive(dot)com
Web: www.pervasive.com

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-05-03 18:23:08 Re: drop database command blocking other connections
Previous Message Tom Lane 2006-05-03 18:14:34 Re: Automatic free space map filling