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