Re: Better client reporting for "immediate stop" shutdowns
От | Andres Freund |
---|---|
Тема | Re: Better client reporting for "immediate stop" shutdowns |
Дата | |
Msg-id | 20201226191627.nowyox3chvk4mjhk@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Better client reporting for "immediate stop" shutdowns (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Better client reporting for "immediate stop" shutdowns
|
Список | 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
В списке pgsql-hackers по дате отправления: