Re: Some code cleanup for pgbench and pg_verifybackup - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Some code cleanup for pgbench and pg_verifybackup
Date
Msg-id alpine.DEB.2.22.394.2107271136000.297424@pseudo
Whole thread Raw
In response to Re: Some code cleanup for pgbench and pg_verifybackup  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Some code cleanup for pgbench and pg_verifybackup
List 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.

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pg_settings.pending_restart not set when line removed
Next
From: "Daniel Westermann (DWE)"
Date:
Subject: Small typo in variable.c