On Mon, Sep 10, 2012 at 10:44:57PM -0700, Jeff Davis wrote: > For the archives, and for those not following the paper in detail, there > is one situation in which SSI will abort a read-only transaction. > > When there are three transactions forming a dangerous pattern where T1 > (read-only) has a conflict out to T2, and T2 has a conflict out to T3; > and T3 is committed and T2 is prepared (for two-phase commit). In that > situation, SSI can't roll back the committed or prepared transactions, > so it must roll back the read-only transaction (T1).
This is true, but it isn't the only situation where a read-only transaction can be rolled back -- this can happen even without two-phase commit involved. You can have a situation where two read/write transactions T2 and T3 conflict such that T2 appears to have executed first in the serial order, but T3 commits before T2. If there's a read-only transaction T1 that takes its snapshot between when T3 and T2 commit, it can't be allowed to read the data that the other two transactions modified: it'd see the changes made by T3 but not T2, violating the serial order. Given a choice, we'd prevent this by aborting one of the read/write transactions. But if they've both already committed by the time the read-only transaction T1 does its reads, we'd have to abort it instead. (Note that this is still an improvement over two-phase locking, which wouldn't allow any of the transactions to execute concurrently!) What I was getting at in my previous mail was that there aren't any situations where COMMIT will return a serialization failure for a read-only transaction. Dan -- Dan R. K. Ports UW CSE http://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
