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

On Fri, 4 Jul 2025 13:01:12 +0000
"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com> wrote:

> Thanks for the diagram, it's quite helpful. Let me share my understanding and opinion.
> 
> The terminology "retry" is being used for the transition CSTATE_ERROR->CSTATE_RETRY,
> and here the random state would be restored to be the begining:
> 
> ```
>                 /*
>                  * Reset the random state as they were at the beginning of the
>                  * transaction.
>                  */
>                 st->cs_func_rs = st->random_state;
> ```

Yes. The random state is reset in the CSTATE_RETRY state, which then transitions
directly to CSTATE_START_COMMAND.

> In --continue-on-error case, the transaction CSTATE_WAIT_RESULT->CSTATE_ERROR
> can happen even the reason of failure is not serialization and deadlock.
> Ultimately the pass will reach ...->CSTATE_END_TX->CSTATE_CHOOSE_SCRIPT, the
> beginning of the state machine. cs_func_rs is not overwritten in the route so
> that different random value would be generated, or even another script may be
> chosen. Is it correct?

Yes, that matches my understanding.

> 04.
> ```
>      <term><replaceable>retries</replaceable></term>
>      <listitem>
>       <para>
>        number of retries after serialization or deadlock errors
>        (zero unless <option>--max-tries</option> is not equal to one)
>       </para>
>      </listitem>
> ```
> 
> To confirm; --continue-on-error won't be counted here because it is not "retry",
> in other words, it does not reach CSTATE_RETRY, right?

Right. Transactions marked as failure due to --continue-on-error are not retried
and should not counted here.

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