Hello Marina,
>> If you want 2 transactions, then you have to put them in two scripts,
>> which looks fine with me. Different transactions are expected to be
>> independent, otherwise they should be merged into one transaction.
>
> Therefore if the script consists of several single statements (= several
> transactions), you cannot retry them. For example, the script looked like
> this:
>
> UPDATE xy1 SET x = 1 WHERE y = 1;
> UPDATE xy2 SET x = 2 WHERE y = 2;
> UPDATE xy3 SET x = 3 WHERE y = 3;
>
> If this restriction is ok for you, I'll simplify the code :)
Yes, that is what I'm suggesting. If you want to restart them, you can put
them in 3 scripts.
>> Under these restrictions, ISTM that a retry is something like:
>>
>> case ABORTED:
>> if (we want to retry) {
>> // do necessary stats
>> // reset the initial state (random, vars, current command)
>> state = START_TX; // loop
>> }
>> else {
>> // count as failed...
>> state = FINISHED; // or done.
>> }
>> break;
>
> If we successfully complete a failed transaction block and process its end
> command in CSTATE_END_COMMAND, we may want to make a retry. So do you think
> that in this case it is ok to go to CSTATE_ABORTED at the end of
> CSTATE_END_COMMAND?..
Dunno.
I'm fine with having END_COMMAND skipping to START_TX if it can be done
easily and cleanly, esp without code duplication.
ISTM that ABORTED & FINISHED are currently exactly the same. That would
put a particular use to aborted. Also, there are many points where the
code may go to "aborted" state, so reusing it could help avoid duplicating
stuff on each abort decision.
>> Once this works, maybe it could go a step further by restarting at
>> savepoints. I'd put restrictions there to ease detecting a savepoint
>> so that it cannot occur in a compound command for instance. This would
>> probably require a new state. Fine.
>
> We discussed the savepoints earlier in [1]:
Yep. I'm trying to suggest an incremental path with simple but yet quite
useful things first.
--
Fabien.
