Re: WIP Patch: Pgbench Serialization and deadlock errors

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.