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

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Better client reporting for "immediate stop" shutdowns
Next
From: Peter Eisentraut
Date:
Subject: trailing junk in numeric literals