On Jan11, 2011, at 19:41 , Heikki Linnakangas wrote: > On 11.01.2011 20:08, Florian Pflug wrote: >> Unfortunately, it seems that doing things this way will undermine the >> guarantee >> that retrying a failed SSI transaction won't fail due to the same conflict as >> it did originally. Consider >> >> T1> BEGIN TRANSACTION ISOLATION SERIALIZABLE >> T1> SELECT * FROM T >> T1> UPDATE T ... >> T1> PREPARE TRANSACTION >> >> T2> BEGIN TRANSACTION ISOLATION SERIALIZABLE >> T2> SELECT * FROM T >> T2> UPDATE T ... >> -> Serialization Error >> >> Retrying T2 won't help as long as T1 isn't COMMITTED. > > T2 should block until T1 commits.
The serialization error will occur even if T1 and T2 update *different* rows. This is due to the SELECTs in the interleaved schedule above returning the state of T prior to both T1 and T2. Which of course never the case for a serial schedule. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
