Re: Some code cleanup for pgbench and pg_verifybackup

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Some code cleanup for pgbench and pg_verifybackup
Date: 2021-07-27 09:45:07
Message-ID: alpine.DEB.2.22.394.2107271136000.297424@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello,

>> 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 disagree about the fact that pgbench uses pg_log_fatal() in ways
> that other binaries don't do.

Sure. Then what should be the expected usage of fatal? Doc says:

* Severe errors that cause program termination. (One-shot programs may
* chose to label even fatal errors as merely "errors". The distinction
* is up to the program.)

pgbench is consistent with the doc. I prefer fatal for this purpose to
distinguish these clearly from recoverable errors, i.e. the programs goes
on despite the error, or at least for some time. I think it is good to
have such a distinction, and bgpench has many errors and many fatals,
although maybe some error should be fatal and some fatal should be error…

> For example, other things use pg_log_error() followed by an exit(), but
> not this code.

Sure.

> I am not going to fight hard on that, though.

Me neither.

> That's a set of inconsistences I bumped into while plugging in
> option_parse_int()

Which is a very good thing! I have already been bitten by atoi.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Westermann (DWE) 2021-07-27 10:04:36 Small typo in variable.c
Previous Message Daniel Gustafsson 2021-07-27 09:45:03 Re: pg_settings.pending_restart not set when line removed