Re: kill -KILL: What happens?

On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Florian Pflug <fgp(at)phlo(dot)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