On Mon, Jul 26, 2021 at 03:35:29PM -0400, Alvaro Herrera wrote:
> On 2021-Jul-26, Fabien COELHO wrote:
>> The semantics for fatal vs error is that an error is somehow handled while a
>> fatal is not. If the log message is followed by an cold exit, ISTM that
>> fatal is the right call, and I cannot help if other commands do not do that.
>> ISTM more logical to align other commands to fatal when appropriate.
I disagree. pgbench is an outlier here. There are 71 calls to
pg_log_fatal() in src/bin/, and pgbench counts for 54 of them. It
would be more consistent to align pgbench with the others.
> I was surprised to discover a few weeks ago that pg_log_fatal() did not
> terminate the program, which was my expectation. If every single call
> to pg_log_fatal() is followed by exit(1), why not make pg_log_fatal()
> itself exit? Apparently this coding pattern confuses many people -- for
> example pg_verifybackup.c lines 291ff fail to exit(1) after "throwing" a
> fatal error, while the block at lines 275 does the right thing.
I remember having the same reaction when those logging APIs got
introduced (I may be wrong here), and I also recall that this point
has been discussed, where the conclusion was that the logging should
never exit() directly.
> (In reality we cannot literally just exit(1) in pg_log_fatal(), because
> there are quite a few places that do some other thing after the log
> call and before exit(1), or terminate the program in some other way than
> exit().)
Yes, that's obviously wrong. I am wondering if there is more of
that.
--
Michael