Re: Better client reporting for "immediate stop" shutdowns
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-12-28T20:01:50Z
Lists: pgsql-hackers
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
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