From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Some code cleanup for pgbench and pg_verifybackup
Date: Tue, 27 Jul 2021 08:53:52 +0900
Message-ID: <YP9LEHjcSng0Yk0R@paquier.xyz> (raw)
In-Reply-To: <202107261935.tad2ojwemn3v@alvherre.pgsql>
References: <alpine.DEB.2.22.394.2107260946550.297424@pseudo>
<202107261935.tad2ojwemn3v@alvherre.pgsql>
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: michael@paquier.xyz, alvherre@alvh.no-ip.org, coelho@cri.ensmp.fr, pgsql-hackers@lists.postgresql.org
Subject: Re: Some code cleanup for pgbench and pg_verifybackup
In-Reply-To: <YP9LEHjcSng0Yk0R@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox