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.