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
signature.asc
Description: PGP signature
