Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

> And I'm not sure that we should do all the stuff for savepoints rollbacks 
> because:
> - as I see it now it only makes sense for the deadlock failures;
> - if there's a failure what savepoint we should rollback to and start the 
> execution again?

ISTM that it is the point of having savepoint in the first place, the 
ability to restart the transaction at that point if something failed?

> Maybe to go to the last one, if it is not successful go to the previous 
> one etc. Retrying the entire transaction may take less time..

Well, I do not know that. My 0.02 € is that if there was a savepoint then 
this is natural the restarting point of a transaction which has some 
recoverable error.

Well, the short version may be to only do a full transaction retry and to 
document that for now savepoints are not handled, and to let that for 
future work if need arises.

>> Maybe something like:
>>   ...
>>   number of failures: 12 (0.004%)
>>   number of retries: 64 (deadlocks: 29, serialization: 35)
>
> Ok! How to you like the idea to use the same format (the total number of 
> transactions with failures and the number of retries for each failure type) 
> in other places (log, aggregation log, progress) if the values are not 
> "default" (= no failures and no retries)?

For progress the output must be short and readable, and probably we do not 
care about whether retries came from this or that, so I would let that 
out.

For log and aggregated log possibly that would make more sense, but it 
must stay easy to parse.

-- 
Fabien.