Re: Latch implementation that wakes on postmaster death on both win32 and Unix - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Latch implementation that wakes on postmaster death on both win32 and Unix
Date
Msg-id 4E172C0F.4040508@enterprisedb.com
Whole thread Raw
In response to Re: Latch implementation that wakes on postmaster death on both win32 and Unix  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Latch implementation that wakes on postmaster death on both win32 and Unix  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
On 08.07.2011 18:56, Peter Geoghegan wrote:
> On 8 July 2011 15:58, Florian Pflug<fgp@phlo.org>  wrote:
>> Also, none of the callers of WaitLatch() seems to actually inspect
>> the WL_POSTMASTER_DEATH bit of the result. We might want to make
>> their !PostmasterIsAlive() check conditional on the WL_POSTMASTER_DEATH
>> bit being set. At least in the case of SyncRepWaitForLSN(), it seems
>> that avoiding the extra read() syscall might be beneficial.
>
> I don't think so. Postmaster death is an anomaly, so why bother with
> any sort of optimisation for that case?

We currently call PostmasterIsAlive() on every iteration of the loop, 
and what Florian is saying is that it would be more efficient to only 
call PostmasterIsAlive() if WaitLatch() reports that the postmaster has 
died. That's an optimization that would help the case where postmaster 
has not died. However, I don't think it makes any difference in practice 
because the loop usually only iterates once, and there's break 
statements to exit the loop as soon as one of the other exit conditions 
are satisfied.

I just committed the v8 of the patch, BTW, after fixing the comment typo 
you pointed out. Thanks!

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: blog post on ancient history
Next
From: Jeff Davis
Date:
Subject: Re: [GENERAL] Creating temp tables inside read only transactions