On 08.07.2011 13:58, Florian Pflug wrote:
> On Jul8, 2011, at 11:57 , Peter Geoghegan wrote:
>> On 7 July 2011 19:15, Robert Haas<robertmhaas@gmail.com> wrote:
>>>> I'm not concerned about the possibility of spurious extra cycles of
>>>> auxiliary process event loops - should I be?
>>>
>>> A tight loop would be bad, but an occasional spurious wake-up seems harmless.
>>
>> We should also assert !PostmasterIsAlive() from within the latch code
>> after waking due to apparent Postmaster death. The reason that I don't
>> want to follow Florian's suggestion to check it in production is that
>> I don't know what to do if the postmaster turns out to be alive. Why
>> is it more reasonable to try again than to just return?
>
> I'd say return, but don't indicate postmaster death in the return value
> if PostmasterIsAlive() returns true. Or don't call PostmasterIsAlive() in
> WaitLatch(), and return indicating postmaster death whenever select()
> says so, and put the burden of re-checking on the callers.
I put the burden on the callers. Removing the return value from
WaitLatch() altogether just makes life unnecessarily difficult for
callers that could safely use that information, even if you sometimes
get spurious wakeups. In particular, the coding in pgarch.c is nicer if
you can simply check the return code for WL_TIMEOUT, rather than call
time(NULL) to figure out if the timeout was reached.
Attached is a new version of this patch. PostmasterIsAlive() now uses
read() on the pipe instead of kill().
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com