Re: Synchronous replication

On 05/08/10 13:40, Fujii Masao wrote:
> On Wed, Aug 4, 2010 at 12:35 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>> There's some race conditions with the signaling. If another process finishes
>> XLOG flush and sends the signal when a walsender has just finished one
>> iteration of its main loop, walsender will reset xlogsend_requested and go
>> to sleep. It should not sleep but send the pending WAL immediately.
>
> Yep. To avoid that race condition, xlogsend_requested should be reset to
> false after sleep and before calling XLogSend(). I attached the updated
> version of the patch.

There's still a small race condition: if you receive the signal just 
before entering pg_usleep(), it will not be interrupted.

Of course, on platforms where signals don't interrupt sleep, the problem 
is even bigger. Magnus reminded me that we can use select() instead of 
pg_usleep() on such platforms, but that's still vulnerable to the race 
condition.

ppoll() or pselect() could be used, but I don't think they're fully 
portable. I think we'll have to resort to the self-pipe trick mentioned 
in the Linux select(3) man page:

>   On systems that  lack  pselect(),  reliable  (and
>        more  portable)  signal  trapping  can  be achieved using the self-pipe
>        trick (where a signal handler writes a byte to a pipe whose  other  end
>        is monitored by select() in the main program.)

Another idea is to use something different than Unix signals, like 
ProcSendSignal/ProcWaitForSignal which are implemented using semaphores.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com