]> granicus.if.org Git - postgresql/commit
Block signals earlier during postmaster startup.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 5 Apr 2014 22:16:17 +0000 (18:16 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 5 Apr 2014 22:16:17 +0000 (18:16 -0400)
commit093d3da1dc3cfcf3209fa44d3fdacf7fcd349e93
treef08b3e63f0f478f4656c5ea52a528fa23b8fa63e
parentcb11f4d8d5d7fd171621b8ee6262cd42bc4e9e07
Block signals earlier during postmaster startup.

Formerly, we set up the postmaster's signal handling only when we were
about to start launching subprocesses.  This is a bad idea though, as
it means that for example a SIGINT arriving before that will kill the
postmaster instantly, perhaps leaving lockfiles, socket files, shared
memory, etc laying about.  We'd rather that such a signal caused orderly
postmaster termination including releasing of those resources.  A simple
fix is to move the PostmasterMain stanza that initializes signal handling
to an earlier point, before we've created any such resources.  Then, an
early-arriving signal will be blocked until we're ready to deal with it
in the usual way.  (The only part that really needs to be moved up is
blocking of signals, but it seems best to keep the signal handler
installation calls together with that; for one thing this ensures the
kernel won't drop any signals we wished to get.  The handlers won't get
invoked in any case until we unblock signals in ServerLoop.)

Per a report from MauMau.  He proposed changing the way "pg_ctl stop"
works to deal with this, but that'd just be masking one symptom not
fixing the core issue.

It's been like this since forever, so back-patch to all supported branches.
src/backend/postmaster/postmaster.c