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: <20201228191428.p5bhcvd4ixsuyifd@alap3.anarazel.de>
References: <559291.1608587013@sss.pgh.pa.us>
 <20201225230331.hru3u6obyy6j53tk@alap3.anarazel.de>
 <1293510.1609007835@sss.pgh.pa.us>
 <20201226191627.nowyox3chvk4mjhk@alap3.anarazel.de>
 <1730644.1609179914@sss.pgh.pa.us>
 <20201228191428.p5bhcvd4ixsuyifd@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 28 Dec 2020 11:14:28 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1819454.1609185710.1@sss.pgh.pa.us>
Date: Mon, 28 Dec 2020 15:01:50 -0500
Message-ID: <1819455.1609185710@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> I don't think it needs to be done right now, but I again want to suggest
> it'd be nice if we split log levels into a bitmask. If we bits, separate
> from the log level, for do-not-log-to-client and do-not-log-to-server
> some of this code would imo look nicer.

Hmm, maybe.  I agree that would be better done as a separate patch though.

I had a thought while looking at elog.c: we could further reduce the risk
of quickdie() crashing if we make it do what elog.c does when it gets into
error recursion trouble:

            error_context_stack = NULL;
            debug_query_string = NULL;

Not invoking error context callbacks would significantly reduce the
footprint of code that can be reached from quickdie's ereports, and
the current call stack isn't really relevant to a report of SIGQUIT
anyway.  The argument for not reporting debug_query_string is a little
thinner, but if that string is long it could result in additional
palloc work inside elog.c, thus increasing the amount of stuff that
has to work to get the report out.

			regards, tom lane