From: "Robert Haas" <robertmh...@gmail.com>
On Fri, Jun 21, 2013 at 2:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
