From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Some code cleanup for pgbench and pg_verifybackup |
Date: | 2021-07-26 19:35:29 |
Message-ID: | 202107261935.tad2ojwemn3v@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Jul-26, Fabien COELHO wrote:
> > - pgbench and pg_verifybackup make use of pg_log_fatal() to report
> > some failures in code paths dedicated to command-line options, which
> > is inconsistent with all the other tools that use pg_log_error().
>
> 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 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.
(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().)
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
Essentially, you're proposing Kevlar shoes as a solution for the problem
that you want to walk around carrying a loaded gun aimed at your foot.
(Tom Lane)
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-07-26 19:53:20 | Re: needless complexity in StartupXLOG |
Previous Message | Tomas Vondra | 2021-07-26 19:26:26 | Re: list of extended statistics on psql (\dX) |