Andres Freund <andres(at)anarazel(dot)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