On Fri, May 6, 2011 at 8:16 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> Could you please expand upon this? Why is it of any consequence if the
> archiver notices that the postmaster is dead after 60 seconds rather
> than after 1? So control in the archiver is going to stay in its event
> loop for longer than it would have before, until pgarch_MainLoop()
> finally returns. The DBA might be required to kill the archiver where
> before they wouldn't have been (they wouldn't have had time to), but
> they are also required to kill other backends anyway before deleting
> postmaster.pid, or there will be dire consequences. Nothing important
> happens after waiting on the latch but before checking
> PostmasterIsAlive(), and nothing important happens after the
> postmaster is found to be dead. ISTM that it wouldn't be particularly
> bad if the archiver was SIGKILL'd while waiting on a latch.
Well, IMHO, the desirable state of affairs is for all child processes,
including regular backends, to exit near-instantaneously once the
postmaster dies. Among many other problems, once the postmaster is
gone, there's no guard against shared memory corruption. And as long
as there is at least one backend kicking around attached to shared
memory, you won't be able to restart postmaster, which is something
you typically want to do as quickly as humanly possible.
http://www.postgresql.org/support/submitbug
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
