Re: Better client reporting for "immediate stop" shutdowns - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Better client reporting for "immediate stop" shutdowns
Date
Msg-id 20201226191627.nowyox3chvk4mjhk@alap3.anarazel.de
Whole thread Raw
In response to Re: Better client reporting for "immediate stop" shutdowns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Better client reporting for "immediate stop" shutdowns
List 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 by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: SQL/JSON: functions
Next
From: Zhihong Yu
Date:
Subject: Re: SQL/JSON: JSON_TABLE