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 |
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 |