On 2013-06-21 23:19:27 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Fri, Jun 21, 2013 at 5:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> The traditional theory has been that that would be less robust, not > >> more so. Child backends are (mostly) able to carry out queries whether > >> or not the postmaster is around. > > > I think that's the Tom Lane theory. The Robert Haas theory is that if > > the postmaster has died, there's no reason to suppose that it hasn't > > corrupted shared memory on the way down, or that the system isn't > > otherwise heavily fuxxored in some way. > > Eh? The postmaster does its level best never to touch shared memory > (after initialization anyway).
I am not sure that will never happen - but I think the chain of argument misses the main point. Normally we rely on the postmaster to kill off all other backends if a backend PANICs or segfaults for all the known reasons. As soon as there's no postmaster anymore we loose that capability. And *that* is scary imo. Especially as I would say the chance of getting PANICs or segfaults increases if there's no postmaster anymore since we might reach code branches we otherwise won't. > >> True, you can't make new connections, > >> but how does killing the existing children make that better? > > > It allows you to start a new postmaster in a timely fashion, instead > > of waiting for an idle connection that may not ever terminate without > > operator intervention. And it's no always easy to figure out which cluster those backends belong to if there are multiple postgres instances running as the same user. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
