Some code cleanup for pgbench and pg_verifybackup

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Some code cleanup for pgbench and pg_verifybackup
Date: 2021-07-26 07:01:08
Message-ID: YP5dtCVuVP6boi69@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

While looking at the code areas of $subject, I got surprised about a
couple of things:
- pgbench has its own parsing routines for int64 and double, with
an option to skip errors. That's not surprising in itself, but, for
strtodouble(), errorOK is always true, meaning that the error strings
are dead. For strtoint64(), errorOK is false only when parsing a
Variable, where a second error string is generated. I don't really
think that we need to be that pedantic about the type of errors
generated in those code paths when failing to parse a variable, so I'd
like to propose a simplification of the code where we reuse the same
error message as for double, cutting a bit the number of translatable
strings.
- pgbench and pg_verifybackup make use of pg_log_fatal() to report
some failures in code paths dedicated to command-line options, which
is inconsistent with all the other tools that use pg_log_error().

Please find attached a patch to clean up all those inconsistencies.

Thoughts?
--
Michael

Attachment Content-Type Size
pgbench-verifybackup-cleanups.patch text/x-diff 11.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-07-26 07:07:20 Re: something is wonky with pgbench pipelining
Previous Message Michael Paquier 2021-07-26 06:01:35 Re: Incorrect usage of strtol, atoi for non-numeric junk inputs