Re: Synchronous replication: sleeping - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Synchronous replication: sleeping
Date
Msg-id 3f0b79eb0812081839s285449dfibebd94cc5380fdfb@mail.gmail.com
Whole thread Raw
In response to Re: Synchronous replication: sleeping  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On Mon, Dec 8, 2008 at 10:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>> On Mon, Dec 08, 2008 at 01:12:39PM +0200, Heikki Linnakangas wrote:
>>> BTW, on what platforms signal doesn't interrupt sleep?
>
>> In theory, none.
>
> In practice, they exist.  In particular I can demonstrate the issue
> on HPUX 10.20.  I also dispute your claim that the behavior is
> forbidden by standards,  For example, the Single Unix Spec
> http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
> saith
>
>        If SA_RESTART has been set for the interrupting signal, it is
>        implementation-dependent whether select() restarts or returns with
>        [EINTR].
>
> and since we set SA_RESTART for most everything, we are exposed to the
> implementation dependency.
>
> I complained about this previously, but nothing came of it:
> http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php

Umm... it's difficult problem. Is it OK if SA_RESTART is removed from only the
signals which walsender uses, and EINTR handling is added into every system
call which walsender uses? Some system calls which walsender uses already
have EINTR handling, for example pq_recvbuf handles EINTR by recv().

Does anyone have a better idea?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Andrew Chernow
Date:
Subject: Re: parallel restore vs. windows
Next
From: Andrew Dunstan
Date:
Subject: Re: parallel restore vs. windows