On 05/08/10 13:40, Fujii Masao wrote:
On Wed, Aug 4, 2010 at 12:35 AM, Heikki Linnakangas
<heikki.linnakan...@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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to