On 19/08/10 20:18, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> On 19/08/10 19:57, Tom Lane wrote:
>>> Hmm, but couldn't you still do that inside pg_usleep? Signal handlers
>>> that do that couldn't know if they were interrupting a sleep per se,
>>> so this would have to be a backend-wide convention.
>
>> I don't understand, do what inside pg_usleep()?
>
> I was envisioning still using pg_usleep, and having this interaction
> between signal handlers and the delay be private to pg_usleep, rather
> than putting such ugly code into forty-nine different places. There
> are a *lot* of places where we have loops that break down delays
> into at-most-one-second pg_usleep calls, and if we're going to have a
> hack like this we should fix them all, not just two or three that SR
> cares about.
Hmm, will need to think about a suitable API for that. The nice thing
would be that we could implement it using pselect() where available.
(And reliable - the Linux select() man page says that glibc's pselect()
is emulated using select(), and suffers from the very same race
condition pselect() was invented to solve. How awful is that!?)
> But I'm still not seeing how this self-pipe hack avoids a race
> condition. If the signal handler is sending a byte whenever it
> executes, then you could have bytes already stacked up in the pipe
> from previous interrupts that didn't happen to come while inside
> pg_usleep. If you clear those before sleeping, you have a race
> condition, and if you don't, then you fail to sleep the intended
> amount of time even though there was no interrupt this time.
You clear the pipe after waking up. Before sending all the pending WAL
and deciding that you're fully caught up again:
for(;;)
{ 1. select() 2. clear pipe 3. send any pending WAL
}
There's more information on the self-pipe trick at e.g
http://lwn.net/Articles/177897/
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com