Re: Suggestion to add --continue-client-on-abort option to pgbench - Mailing list pgsql-hackers

From Yugo Nagata
Subject Re: Suggestion to add --continue-client-on-abort option to pgbench
Date
Msg-id 20250926115234.962c12ce997bee78883a0c3f@sraoss.co.jp
Whole thread Raw
In response to Re: Suggestion to add --continue-client-on-abort option to pgbench  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
List pgsql-hackers
On Thu, 25 Sep 2025 10:27:44 +0200
Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> wrote:

> Hi,
> 
> The patch looks good, I've spotted some typos in the doc.
> 
> +        Allows clients to continue their run even if an SQL statement
> fails due to
> +        errors other than serialization or deadlock. Unlike
> serialization and deadlock
> +        failures, clients do not retry the same transactions but
> start new transaction.
> 
> Should be "but start a new transaction.", although "proceed to the
> next transaction." may be clearer here that ?
> 
> +       number of transactions that got a SQL error
> +       (zero unless <option>--failures-detailed</option> is specified)
> 
> It seems like both "a SQL" and "an SQL" are used in the codebase and
> doc, but this page only uses "an SQL", so using "an SQL" may be better
> for consistency.
> 
> +   If an SQL command fails due to serialization or deadlock errors, the
> +   client does not aborted, regardless of whether
> 
> Should be "the client does not abort."

Thank you for your review.
I've attached the updated patch in my previous post in this thread.

By the way, on the pgsql-hackers list, top-posting is generally discouraged [1],
so replying below the quoted messages is usually preferred.

[1] https://wiki.postgresql.org/wiki/Mailing_Lists

Regards,
Yugo Nagata

-- 
Yugo Nagata <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Remove unused for_all_tables field from AlterPublicationStmt
Next
From: Chao Li
Date:
Subject: Re: Mark ItemPointer arguments as const thoughoutly