Re: kill -KILL: What happens?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Florian Pflug <fgp@phlo.org>, David Fetter <david@fetter.org>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2011-01-14T03:03:53Z
Lists: pgsql-hackers
On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Florian Pflug <fgp@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