On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Florian Pflug <f...@phlo.org> writes: >>>> So maybe there should be a GUC for this? > >>> No need (and rather inflexible anyway). If you don't want an orphaned >>> backend to continue, you send it SIGTERM. > >> It is not easy to make this work in such a way that you can ensure a >> clean, automatic restart of PostgreSQL after a postmaster death. >> Which is what at least some people want. > > True. It strikes me also that the postmaster does provide some services > other than accepting new connections: > > * ensuring that everybody gets killed if a backend crashes > > * respawning autovac launcher and other processes that might exit > harmlessly > > * is there still any cross-backend signaling that goes through the > postmaster? We got rid of the sinval case, but I don't recall if > there's others. > > While you could probably live without these in the scenario of "let my > honking big query finish before restarting", you would not want to do > without them in unattended operation.
Yep. I'm pretty doubtful that you're going to want them even in that case, but you're surely not going to want them in unattended operation. -- 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
