Better client reporting for "immediate stop" shutdowns
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2020-12-21T21:43:33Z
Lists: pgsql-hackers
Attachments
- report-immediate-stop-more-clearly-1.patch (text/x-diff) patch
Up to now, if you shut down the database with "pg_ctl stop -m immediate" then clients get a scary message claiming that something has crashed, because backends can't tell whether the SIGQUIT they got was sent for a crash-and-restart situation or because of an immediate-stop command. This isn't great from a fit-and-finish perspective, and it occurs to me that it's really easy to do better: the postmaster can stick a flag into shared memory explaining the reason for SIGQUIT. While we don't like the postmaster touching shared memory, there doesn't seem to be any need for interlocking or anything like that, so there is no risk involved that's greater than those already taken by pmsignal.c. So, here's a very simple proposed patch. Some issues for possible bikeshedding: * Up to now, pmsignal.c has only been for child-to-postmaster communication, so maybe there is some better place to put the support code. I can't think of one though. * I chose to report the same message for immediate shutdown as we already use for SIGTERM (fast shutdown or pg_terminate_backend()). Should it be different, and if so what? regards, tom lane
Commits
-
Suppress log spam from multiple reports of SIGQUIT shutdown.
- 1f9158ba4812 14.0 landed
-
Improve client error messages for immediate-stop situations.
- 7e784d1dc191 14.0 landed