SIGQUIT vs SIGINT

[Edwin Grubbs]

Redhat cluster comes with a default configuration file for
postgres-8.4 that by default just sends a SIGQUIT to stop postgres.
I'm trying to convince Redhat support to use SIGINT instead of
SIGQUIT, so that postgres doesn't have to recover by replaying the WAL
file, but they are questioning whether recovery is actually a bad
thing.

I can't find any more information on why not to use SIGQUIT besides
the documentation indicating "This is recommended only in
emergencies." Can you provide any information on why their default
config should be changed? I can obviously edit my own server's config,
but I don't want anyone else to be hurt by this.

Here is the bug that I submitted. The comments that I have received
back are on the support ticket, so you can't see that.
https://bugzilla.redhat.com/show_bug.cgi?id=871659

-Edwin

[Tom Lane]

Post by Edwin Grubbs
Redhat cluster comes with a default configuration file for
postgres-8.4 that by default just sends a SIGQUIT to stop postgres.

Ouch. That's news to me.

Post by Edwin Grubbs
I can't find any more information on why not to use SIGQUIT besides
the documentation indicating "This is recommended only in
emergencies." Can you provide any information on why their default
config should be changed?

You already pointed out the core reason: it results in substantially
increased time to restart the service, because of the need for WAL
replay.

One could also argue that there's an increased risk of data corruption,
because that's a relatively poorly tested shutdown sequence. (Sure,
we would like to think that SIGQUIT is perfectly safe, but it's poorly
tested.) One thought that comes to mind is that because the postmaster
exits without waiting for its children, the postmaster.pid lock file
will be removed before all activity has stopped, meaning that there is a
nonzero risk of data corruption if a new postmaster is started
immediately afterwards.

Another argument is that SIGQUIT does not allow for a clean shutdown
of client connections, which could confuse client-side logic with
difficult-to-predict consequences.

There are probably some other risks I'm not thinking of.

Basically, SIGQUIT is the panic button. You push it when there is a
damn good reason to, not when you are doing a routine shutdown.
http://en.wikipedia.org/wiki/Big_red_button

Post by Edwin Grubbs
Here is the bug that I submitted. The comments that I have received
back are on the support ticket, so you can't see that.
https://bugzilla.redhat.com/show_bug.cgi?id=871659

FWIW, I've added a private comment to that bugzilla encouraging a
change.

regards, tom lane