Andres Freund <and...@anarazel.de> wrote: > On Tuesday 02 November 2010 18:33:15 Kevin Grittner wrote: >> Well, on a ROLLBACK I'm not sure it's a problem. On a COMMIT, >> couldn't you call a function to check for it in CommitTransaction >> and PrepareTransaction? > Sure, throwing an error somewhere wouldnt be that hard. But at the > moment a COMMIT is always successfull (and just reporting a > ROLLBACK in a failed txn). > Doesn't seem to be something to changed lightly. Well, I'm looking at using this with the Serializable Snapshot Isolation (SSI) patch, which can throw an error from a COMMIT, if the commit completes the conditions necessary for an anomaly to occur (i.e., the committing transaction is on the rw-conflict *out* side of a pivot, and it is the first in the set to commit). If we succeed in enhancing SSI to use lists of rw-conflicted transactions rather than its current techniques, we might be able to (and find it desirable to) always commit in that circumstance and roll back some *other* transaction which is part of the problem. Of course, that other transaction might be idle at the time, and the next thing *it* tries to execute *might* be a COMMIT. So if the SSI patch goes in, there will always be some chance that a COMMIT can fail, but doing it through the mechanism your patch provides could improve performance, because we could guarantee that nobody ever has a serialization failure without first successfully committing a transaction which wrote to one or more tables. If a commit fails due to SSI, it is highly desirable that the error use the serialization failure SQLSTATE, so that an application framework can know that it is reasonable to retry the transaction. > Does anybody have any idea why COMMIT is allowed there? Seems > pretty strange to me. So that the "failed transaction" state can be cleared. The transaction as a whole has failed, but you don't want the connection to become useless. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
