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

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Yugo Nagata' <nagata(at)sraoss(dot)co(dot)jp>, ikedarintarof <ikedarintarof(at)oss(dot)nttdata(dot)com>
Cc: "slpmcf(at)gmail(dot)com" <slpmcf(at)gmail(dot)com>, "boekewurm+postgres(at)gmail(dot)com" <boekewurm+postgres(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <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 10:59:09
Message-ID: OSCPR01MB149668976E286CEBA316A5BF6F545A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Nagata-san, Ikeda-san,

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

OK, so let's do like that.

BTW, initially we were discussing the combination of --continue-on-error and
--exit-on-abort. What it the conclusion?
I feel the Nagata-san's point [1] is valid in this approach.

> > > 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 intended here that clients could throw away the failed transaction and start
new one again in the case. I hope we are on the same page...

[1]: https://www.postgresql.org/message-id/20250614002453.5c72f2ec80864d840150a642%40sraoss.co.jp

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2025-06-27 11:02:22 Re: [PATCH] Add tests for binaryheap.c
Previous Message Ajin Cherian 2025-06-27 10:29:53 Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state