pg.ddx.io pgsql-admin@postgresql.org mailing list archivehelp / color / mirror / Atom feed
SIGQUIT vs SIGINT 2+ messages / 2 participants [nested] [flat]
* SIGQUIT vs SIGINT @ 2012-11-06 21:03 Edwin Grubbs <edwin@grubbs.org> 0 siblings, 1 reply; 2+ messages in thread From: Edwin Grubbs @ 2012-11-06 21:03 UTC (permalink / raw) To: pgsql-admin 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 ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: SIGQUIT vs SIGINT @ 2012-11-06 21:53 Tom Lane <tgl@sss.pgh.pa.us> parent: Edwin Grubbs <edwin@grubbs.org> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2012-11-06 21:53 UTC (permalink / raw) To: Edwin Grubbs <edwin@grubbs.org>; +Cc: pgsql-admin Edwin Grubbs <edwin@grubbs.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 ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2012-11-06 21:53 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2012-11-06 21:03 SIGQUIT vs SIGINT Edwin Grubbs <edwin@grubbs.org> 2012-11-06 21:53 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox