Re: Better client reporting for "immediate stop" shutdowns
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-12-26T19:16:27Z
Lists: pgsql-hackers
Hi, On 2020-12-26 13:37:15 -0500, Tom Lane wrote: > I suppose a compromise position could be to let the postmaster export its > "Shutdown" state variable, and then let backends assume that SIGTERM means > fast shutdown or pg_terminate_backend depending on the state of that one > global variable. But it'd be a bit imprecise so I don't really feel it's > more useful than what we have. Fair enough, I think. > > I'd like to not log all these repeated messages into the server > > log. It's quite annoying to have to digg through thousands of lines of > > repeated "terminating connection..." > > Hm. That's an orthogonal issue, but certainly worth considering. > There are a couple of levels we could consider: > > 1. Just make the logged messages less verbose (they certainly don't > need the DETAIL and HINT lines). > > 2. Suppress the log entries altogether. > > I would have been against #2 before this patch, because it'd mean > that a rogue SIGQUIT leaves no clear trace in the log. But with > this patch, we can be fairly sure that we know whether SIGQUIT came > from the postmaster, and then it might be all right to suppress the > log entry altogether when it did. > > I'd be happy to write up a patch for either of these, but let's > decide what we want first. My vote would be #2, with the same reasoning as yours. Greetings, Andres Freund
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