On 19/08/10 19:57, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> On 19/08/10 16:38, Tom Lane wrote:
>>> Considering that pg_usleep is implemented with select, I'm not following
>>> what you mean by "replace pg_usleep() with select()"?
>
>> Instead of using pg_usleep(), call select() directly, waiting not only
>> for the timeout, but also for data to arrive on the "self-pipe". The
>> signal handler writes a byte to the self-pipe, waking up the select().
>> That way the select() is interupted by the signal arriving, even if
>> signals per se don't interrupt it. And it closes the race condition
>> involved with setting a flag in the signal handler and checking that in
>> the main loop.
>
> 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()?
We only need to respond quickly to one signal, the one that tells
walsender "there's some new WAL that you should send". We can rely on
polling for all the other signals like SIGHUP for config reload or
shutdown request, like we do today.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
