From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Better client reporting for "immediate stop" shutdowns |
Date: | 2020-12-21 21:43:33 |
Message-ID: | 559291.1608587013@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
report-immediate-stop-more-clearly-1.patch | text/x-diff | 7.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-12-21 21:44:34 | Re: Proposed patch for key managment |
Previous Message | Bruce Momjian | 2020-12-21 21:35:14 | Re: Proposed patch for key managment |