On Fri, May 6, 2011 at 10:13 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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
The apparently irrelevant link at the bottom of this email is the
result of a cut-and-paste into the wrong email window. Sorry....
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
