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

From Robert Haas
Subject Re: Latch implementation that wakes on postmaster death on both win32 and Unix
Date
Msg-id CA+TgmobiZwEsqKOipi8v_yHyytRgdgbyUmStM6Hh0vjeQhZLpg@mail.gmail.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
List pgsql-hackers
On Thu, Jul 7, 2011 at 1:41 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> I now think that we shouldn't change the return value format from the
> most recent revisions of the patch (i.e. returning a bitfield). We
> should leave it as-is, while documenting that it's possible, although
> extremely unlikely, for it to incorrectly report Postmaster death, and
> that clients therefore have a onus to check that themselves using
> PostmasterIsAlive(). We already provide fairly weak guarantees as to
> the validity of that return value ("Note that if multiple wake-up
> conditions are true, there is no guarantee that we return all of them
> in one call, but we will return at least one"). Making them a bit
> weaker still seems acceptable.

I agree - that seems like a good way to handle it.

> In addition, we'd change the implementation of PostmasterIsAlive() to
> /just/ perform the read() test as already described.
>
> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Inconsistency between postgresql.conf and docs
Next
From: Robert Haas
Date:
Subject: Re: Avoid index rebuilds for no-rewrite ALTER TABLE ALTER TYPE