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

From Robert Haas
Subject Re: kill -KILL: What happens?
Date
Msg-id AANLkTimf3ujv7FyjjPkaTeFVThT7FFEYuCwEBBHX0MHn@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?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: kill -KILL: What happens?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 13, 2011 at 3:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I wonder whether we could have some sort of latch-like counter that
>>> would count the number of active backends and deliver signals when the
>>> count went to zero.  However, if the goal is to defend against random
>>> applications of SIGKILL, there's probably no way to make this reliable
>>> in userspace.
>
>> I don't think you can get there 100%.  We could, however, make a rule
>> that when a background process fails a PostmasterIsAlive() check, it
>> sends SIGQUIT to everyone it can find in the ProcArray, which would at
>> least ensure a timely exit in most real-world cases.
>
> You're going in the wrong direction there: we're trying to have the
> system remain sane when the postmaster crashes, not see how quickly
> it can screw up every remaining session.

I strongly believe you're in the minority on that one, for the same
reasons that I don't think most people would agree with your notion of
what should be the default shutdown mode.  A database that can't
accept new connections is a liability, not an asset.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: kill -KILL: What happens?
Next
From: Robert Haas
Date:
Subject: Re: Allowing multiple concurrent base backups