On Fri, May 6, 2011 at 10:13 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, May 6, 2011 at 8:16 AM, Peter Geoghegan <pe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
