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