Re: Better client reporting for "immediate stop" shutdowns

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Better client reporting for "immediate stop" shutdowns
Дата
Msg-id 20201228191428.p5bhcvd4ixsuyifd@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Better client reporting for "immediate stop" shutdowns  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Better client reporting for "immediate stop" shutdowns  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2020-12-28 13:25:14 -0500, Tom Lane wrote:
> The most straightforward way to do that is to introduce a new error
> level.  Having to renumber existing levels is a bit of a pain, but
> I'm not aware of anything that should break in source-code terms.
> We make similar ABI breaks in every major release.

I don't see a problem either.


>      /* Select default errcode based on elevel */
>      if (elevel >= ERROR)
>          edata->sqlerrcode = ERRCODE_INTERNAL_ERROR;
> -    else if (elevel == WARNING)
> +    else if (elevel >= WARNING)
>          edata->sqlerrcode = ERRCODE_WARNING;
>      else
>          edata->sqlerrcode = ERRCODE_SUCCESSFUL_COMPLETION;

> @@ -2152,6 +2157,7 @@ write_eventlog(int level, const char *line, int len)
>              eventlevel = EVENTLOG_INFORMATION_TYPE;
>              break;
>          case WARNING:
> +        case WARNING_CLIENT_ONLY:
>              eventlevel = EVENTLOG_WARNING_TYPE;
>              break;
>          case ERROR:
> [...]

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.


Looks good to me.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Better client reporting for "immediate stop" shutdowns
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Better client reporting for "immediate stop" shutdowns