Horton
Menu

Re: Suggestion to add --continue-client-on-abort option to pgbench

Rintaro Ikeda <ikedarintarof@oss.nttdata.com>

View thread
From: ikedarintarof <ikedarintarof@oss.nttdata.com>
To: Yugo Nagata <nagata@sraoss.co.jp>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: slpmcf@gmail.com, boekewurm+postgres@gmail.com, pgsql-hackers@postgresql.org, Srinath Reddy Sadipiralla <srinath2133@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2025-06-27T05:06:24Z
Lists: pgsql-hackers 
Hi,

Thank you very much for your valuable comments and kind advice. I'm 
currently working on revising the previous patch based on the feedback 
received. I would like to share my thoughts regarding the conditions 
under which the --continue-on-error option should initiate a new 
transaction or a new connection.

In my opinion, when the --continue-on-error option is enabled, pgbench 
clients does not need to start new transactions after network errors and 
other errors except for SQL-level errors.

Network errors are relatively rare, except in failover scenarios. 
Outside of failover, any network issues should be resolved rather than 
worked around. In the context of failover, the key metric is not TPS, 
but system downtime. While one might infer the timing of a failover by 
observing by using --progress option, you can easily determine the 
downtime by executing simple SQL query such as `psql -c 'SELECT 1` every 
second.


On 2025/06/26 18:47, Yugo Nagata wrote:
> On Thu, 26 Jun 2025 05:45:12 +0000
> "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com> wrote:
> 
>> Dear Nagata-san,
>> 
>>> As I understand it, the current patch aims to allow continuation only 
>>> after
>>> SQL-level
>>> errors, such as constraint violations. That seems reasonable, as it 
>>> can simulate
>>> the
>>> behavior of applications that ignore or retry such errors (even 
>>> though retries are
>>> not
>>> implemented in the current patch).
>> 
>> Yes, no one has objections to retry in this case. This is a main part 
>> of the proposal.,
> 
> As I understand it, the proposed --continue-on-error option does not 
> retry the transaction
> in any case; it simply gives up on the transaction. That is, when an 
> SQL-level error occurs,
> the transaction is reported as "failed" rather than "retried", and the 
> random state is discarded.

Retrying the failed transaction is not necessary when the transaction 
failed due to SQL-level errors. Unlike real-world applications, pgbench 
does not need to complete specific transaction successfully. In the case 
of unique constraint violations, retrying the same transaction will 
likely to result in the same error again.

I want to hear your thoughts on this.

Best regards,
Rintaro Ikeda

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pgbench: Fix assertion failure with multiple \syncpipeline in pipeline mode.

  2. pgbench: Add --continue-on-error option.

  3. Fix "inconsistent DLL linkage" warning on Windows MSVC

  4. pgbench: Fix error reporting in readCommandResponse().

  5. pgbench: Fix assertion failure with retriable errors in pipeline mode.

  6. Allow pgbench to retry in some cases.