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.

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to