From: "Robert Haas" <robertmhaas@gmail.com>
> On Fri, Jun 21, 2013 at 2:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> More generally, what do we think the point is of sending SIGQUIT
>>> rather than SIGKILL in the first place, and why does that point cease
>>> to be valid after 5 seconds?
>>
>> Well, mostly it's about telling the client we're committing hara-kiri.
>> Without that, there's no very good reason to run quickdie() at all.
>
> That's what I thought, too. It seems to me that if we think that's
> important, then it's important even if it takes more than 5 seconds
> for some reason.
I guess Tom san is saying "we should be as kind as possible to the client,
so try to notify the client of the shutdown". Not complete kindness.
Because the DBA requested immediate shutdown by running "pg_ctl stop -mi",
the top priority is to shutdown the database server as immediately as
possible. The idea here is to try to be friendly to the client as long as
the DBA can stand. That's tthe 5 second.
>> A practical issue with starting to send SIGKILL ourselves is that we
>> will no longer be able to reflexively diagnose "server process died
>> on signal 9" as "the linux OOM killer got you". I'm not at all
>> convinced that the cases where SIGQUIT doesn't work are sufficiently
>> common to justify losing that property.
>
> I'm not, either. Maybe this question will provoke many indignant
> responses, but who in their right mind even uses immediate shutdown on
> a production server with any regularity? The shutdown checkpoint is
> sometimes painfully long, but do you really want to run recovery just
> to avoid it? And in the rare case where an immediate shutdown fails
> to work, what's wrong will "killall -9 postgres"?
Checkpoint is irrelevant here because we are discussing immediate shutdown.
Some problems with "killall -9 postgres" are:
1. It's not available on Windows.
2. It may kill other database server instances running on the same machine.
Regards
MauMau