Block signals earlier during postmaster startup

Enterprise / PostgreSQL - Tom Lane [sss.pgh.pa.us] - 5 April 2014 17:16 UTC

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.

5d8117e Block signals earlier during postmaster startup.
src/backend/postmaster/postmaster.c | 60 +++++++++++++++++------------------
1 file changed, 30 insertions(+), 30 deletions(-)

Upstream: git.postgresql.org

  • Share