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

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: ikedarintarof <ikedarintarof(at)oss(dot)nttdata(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, <slpmcf(at)gmail(dot)com>, <boekewurm+postgres(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Suggestion to add --continue-client-on-abort option to pgbench
Date: 2025-06-27 06:17:11
Message-ID: 20250627151711.59cc50a3b3b5bc428419ddca@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 27 Jun 2025 14:06:24 +0900
ikedarintarof <ikedarintarof(at)oss(dot)nttdata(dot)com> wrote:

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

+1

I agree that --continue-on-error prevents pgbench from terminating only when
SQL-level errors occur, and does not change the behavior in the case of other
types of errors, including network errors.

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

Agreed.

Regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry 2025-06-27 06:41:19 Re: IPC/MultixactCreation on the Standby server
Previous Message Fujii Masao 2025-06-27 06:11:41 Re: ALTER TABLE ALTER CONSTRAINT misleading error message