Re: Unix latch implementation that wakes on postmaster death

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unix latch implementation that wakes on postmaster death
Date: 2011-05-13 12:25:41
Message-ID: BANLkTinq_4F8ScPASCiixZhh=-ahd_jWHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 13, 2011 at 8:06 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> Attached is a patch that builds upon Florian Pflug's earlier proof of
> concept program for monitoring the postmaster. The code creates a
> non-blocking pipe in the postmaster that child processes block on
> using a select() call. This all occurs in the latch code, which now
> monitors postmaster death, but only for clients that request it (and,
> almost invariably in addition to monitoring other things, like having
> a timeout occur or a latch set).
>
> I've implemented an interface originally sketched by Heikki that
> allows clients to specify events to wake on, and to see what event
> actually caused the wakeup when we're done by bitwise AND'ing the
> returned int against various new bitmasks.
>
> I've included my existing changes to the archiver as a convenience to
> anyone that wants to quickly see the effects of the patch in action;
> even though we don't have a tight loop that polls PostmasterIsAlive()
> every second, we still wake up on postmaster death, so there is no
> potential denial of service as previously described by Tom. This can
> be easily observed by sending the postmaster SIGKILL while the
> archiver is on - the archiver immediately finishes. Note that I've
> deferred changing the existing call sites of WaitLatch()/
> WaitLatchOrSocket(), except to make them use the new interface. Just
> as before, they don't ask to be woken on postmaster death, even though
> in some cases they probably should. Whether or not they should and how
> they should are questions for another day though.

I don't immediately have time to look at this, but it sounds awesome!
Thank you very much for working on this!

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-05-13 12:26:29 Re: Formatting Curmudgeons WAS: MMAP Buffers
Previous Message Peter Geoghegan 2011-05-13 12:06:59 Unix latch implementation that wakes on postmaster death