We have had a case where a production cluster was accidentally shut down by a customer who used Ctrl+C in the same sh session in which they had (long before) run pg_ctl start. We have only seen this in sh on Solaris. Other shells on Solaris don't behave this way, nor does sh on tested versions of Linux. Nevertheless, the problem is seen on the default shell for a supported OS.
Analysis suggests that this is because the postmaster retains the process group ID of the original parent (in this case pg_ctl). If pg_ctl is run through the setpgrp command a subsequent Ctrl+C in the sh session does not shut down the PostgreSQL cluster. On my development Linux machine: $ ps axfopid,ppid,pgid,command PID PPID PGID COMMAND [ ... ] 8416 1 8412 /home/kgrittn/pg/master/Debug/bin/postgres -D Debug/data 8418 8416 8418 \_ postgres: checkpointer process 8419 8416 8419 \_ postgres: writer process 8420 8416 8420 \_ postgres: wal writer process 8421 8416 8421 \_ postgres: autovacuum launcher process 8422 8416 8422 \_ postgres: stats collector process 8427 8416 8427 \_ postgres: kgrittn test [local] idle All of the PPID values seem correct, and while the PGID values for backends might initially seem surprising, the commit notes and C comments here explain why each backend sets up its own process group: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3ad0728 What is surprising is that the postmaster doesn't set up its own process group when it is running as a daemon. We probably don't want to change that when postgres is run directly from a command line for development or diagnostic purposes, but Noah suggested perhaps we should add a --daemonize option which pg_ctl should use when launching the postmaster, which would cause it to create its own session group. Although this is arguably a bug, it seems like it is very rarely hit and has several workarounds, and any fix would either change things in a way which might break existing user scripts or would require a new command-line option; so back-patching a fix to stable branches doesn't seem appropriate. I would argue for including a fix in 9.4 on the basis of it being a bug fix and there being time to mention it in the release change notes; but I understand the counter-arguments and realize this is a judgment call. Thoughts? If the new option seems reasonable, I can draft a patch to implement that. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers