Re: kill -KILL: What happens? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: kill -KILL: What happens?
Date
Msg-id AANLkTimbob9+wBVNcBv0nrrLAAMs_A3u_i-oxcOH5EFS@mail.gmail.com
Whole thread Raw
In response to Re: kill -KILL: What happens?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: kill -KILL: What happens?  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: kill -KILL: What happens?
Next
From: Bruce Momjian
Date:
Subject: Re: Fixing GIN for empty/null/full-scan cases