From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Better client reporting for "immediate stop" shutdowns
In-reply-to: <20201225230331.hru3u6obyy6j53tk@alap3.anarazel.de>
References: <559291.1608587013@sss.pgh.pa.us>
 <20201225230331.hru3u6obyy6j53tk@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Fri, 25 Dec 2020 15:03:31 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1293509.1609007835.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 26 Dec 2020 13:37:15 -0500
Message-ID: <1293510.1609007835@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2020-12-21 16:43:33 -0500, Tom Lane wrote:
>> * 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?

[ per upthread, I did already change the SIGQUIT message to specify
"immediate shutdown" ]

> To do better I think we'd have to distinguish the different cases? An
> error message like
> "terminating connection due to {fast shutdown,immediate shutdown,connect=
ion termination} administrator command"
> or such could be helpful, but I don't think your patch adds *quite*
> enough state?

Well, if you want to distinguish different causes for SIGTERM then
you'd need additional mechanism for that.  I think we'd have to have
a per-child termination-reason field, since SIGTERM might be sent to
just an individual backend rather than the whole flotilla at once.
I didn't think it was quite worth the trouble --- "administrator command"
seems close enough for both fast shutdown and pg_terminate_backend() ---
but you could certainly argue differently.

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.

> 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.

			regards, tom lane