Date: Tue, 27 Jul 2021 06:36:15 +0200 (CEST)
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Michael Paquier <michael@paquier.xyz>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
    Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Some code cleanup for pgbench and pg_verifybackup
In-Reply-To: <YP9LEHjcSng0Yk0R@paquier.xyz>
Message-ID: <alpine.DEB.2.22.394.2107270614430.297424@pseudo>
References: <alpine.DEB.2.22.394.2107260946550.297424@pseudo>
 <202107261935.tad2ojwemn3v@alvherre.pgsql> <YP9LEHjcSng0Yk0R@paquier.xyz>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="2056645051-387733313-1627360576=:297424"
Archived-At: 
 <https://www.postgresql.org/message-id/alpine.DEB.2.22.394.2107270614430.297424%40pseudo>
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--2056645051-387733313-1627360576=:297424
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT


Bonjour Michaël-san,

>>> 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 do not understand your disagreement. Do you disagree about the expected 
semantics of fatal? Then why provide fatal if it should not be used?
What is the expected usage of fatal?

I do not dispute that pgbench is a statistical outlier. However, Pgbench 
is somehow special because it does not handle a lot of errors, hence a lot 
of "fatal & exit" pattern is used, and the user has to restart. There are 
76 calls to "exit" from pgbench, but only 23 from psql which is much 
larger. ISTM that most "normal" pg programs won't do that because they are 
nice and try to handle errors.

So for me "fatal" is the right choice before exiting with a non zero 
status, but if "error" is called instead I do not think it matters much, 
you do as you please.

>> I was surprised to discover a few weeks ago that pg_log_fatal() did not
>> terminate the program, which was my expectation.

Mine too.

-- 
Fabien.
--2056645051-387733313-1627360576=:297424--