On Jan14, 2011, at 01:32 , Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Killing active sessions when it's not absolutely necessary is not an >>> asset. > >> That's a highly arguable point and I certainly don't agree with it. > > Your examples appear to rely on the assumption that background processes > exit instantly when the postmaster dies. Which they should not.
Even if they stay around, no new connections will be possible once the postmaster is gone. So this really comes down to what somebody perceives to be a bigger problem - new connections failing or existing connections being terminated. I don't believe there's one right answer to that. Assume postgres is driving a website, and the postmaster crashes shortly after a pg_dump run started. You probably won't want your website to be offline while pg_dump is finishing its backup. If, on the other hand, your data warehousing database is running a multi-hour query, you might prefer that query to finish, even at the price of not being able to accept new connections. So maybe there should be a GUC for this? best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
