> 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.
