Re: Some code cleanup for pgbench and pg_verifybackup
Fabien COELHO <coelho@cri.ensmp.fr>
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>
Date: 2021-07-27T09:45:07Z
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.
Commits
-
Add some missing exit() calls in error paths for various binaries
- 856de3b39cf6 15.0 landed
-
Add missing exit() in pg_verifybackup when failing to find pg_waldump
- efe169c90090 13.4 landed
- 67445deb7eca 14.0 landed
- 2ad98fdf53ed 15.0 landed