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