On Fri, 4 Jul 2025 13:01:12 +0000 "Hayato Kuroda (Fujitsu)" <kuroda.hay...@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 <nag...@sraoss.co.jp>
