Re: SIGQUIT vs SIGINT

Edwin Grubbs <edwin(at)grubbs(dot)org> writes:
> 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.

> 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

> 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