Re: Frontend error logging style - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Frontend error logging style
Date
Msg-id 3fde622f-71de-014f-ff47-b560b080e59f@enterprisedb.com
Whole thread Raw
In response to Frontend error logging style  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 09.11.21 23:20, Tom Lane wrote:
> 1.  The distinction between "error" and "fatal" levels seems squishy
> to the point of uselessness.  I think we should either get rid of it
> entirely, or make an effort to use "fatal" exactly for the cases that
> are going to give up and exit right away.  Of the approximately 830
> pg_log_error calls in HEAD, I count at least 450 that are immediately
> followed by exit(1), and so should be pg_log_fatal if this distinction
> means anything at all.  OTOH, if we decide it doesn't mean anything,
> there are only about 90 pg_log_fatal calls to convert.  I lean
> slightly to the "get rid of the distinction" option, not only because
> it'd be a much smaller patch but also because I don't care to expend
> brain cells on the which-to-use question while reviewing future
> patches.

This logging system has been designed more generally, drawing some 
inspiration from Python and Java libraries, for example.  It's up to the 
program using this to make sensible use of it.  I think there are 
programs such as pg_receivewal where there is a meaningful distinction 
between errors flowing by and a fatal exit.  But with something like 
pg_basebackup, there is no real difference, so that code sort of uses 
pg_log_error by default, since any error is implicitly fatal.  I see the 
apparent inconsistency, but I don't think it's a real problem.  Each 
program by itself has arguably sensible behavior.



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Commitfest 2021-11 Patch Triage - Part 2
Next
From: Peter Eisentraut
Date:
Subject: Re: Frontend error logging style