Re: Frontend error logging style

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Frontend error logging style
Дата
Msg-id 6fdb3ab3-f093-27b9-dfdc-c391e69163fc@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Frontend error logging style  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Frontend error logging style  (Andres Freund <andres@anarazel.de>)
Re: Frontend error logging style  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 23.02.22 00:23, Tom Lane wrote:
> This conversation seems to have tailed off without full resolution,
> but I observe that pretty much everyone except Peter is on board
> with defining pg_log_fatal as pg_log_error + exit(1).  So I think
> we should just do that, unless Peter wants to produce a finished
> alternative proposal.
> 
> I've now gone through and fleshed out the patch I sketched upthread.

This patch already illustrates a couple of things that are wrong with 
this approach:

- It doesn't allow any other way of exiting.  For example, in pg_dump, 
you have removed a few exit_nicely() calls.  It's not clear why that is 
valid or whether it would always be valid for all call sites.

- It doesn't allow other exit codes.  For example, in psql, you have 
changed a pg_log_fatal() call to pg_log_error() because it needed 
another exit code.  This slides us right back into that annoying 
situation where in the backend we have to log error messages using 
elog(LOG) because the flow control is tangled up with the log level.

My suggestion is to just get rid of pg_log_fatal() and replace them all 
with pg_log_error().




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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Optionally automatically disable logical replication subscriptions on error
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: PATCH: add "--config-file=" option to pg_rewind