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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
