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>
