Re: Better client reporting for "immediate stop" shutdowns

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Better client reporting for "immediate stop" shutdowns
Дата
Msg-id 1819455.1609185710@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Better client reporting for "immediate stop" shutdowns  (Andres Freund <andres@anarazel.de>)
Ответы Re: Better client reporting for "immediate stop" shutdowns  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Better client reporting for "immediate stop" shutdowns
Следующее
От: Peter Eisentraut
Дата:
Сообщение: trailing junk in numeric literals