In going back through old emails to see what issues might have been raised but not yet addressed for the SSI patch, I found the subject issue described in a review by Jeff Davis here: http://archives.postgresql.org/pgsql-hackers/2010-10/msg01159.php I think this is already handled based on feedback from Heikki: http://archives.postgresql.org/pgsql-hackers/2010-09/msg00789.php Basically, the PREPARE TRANSACTION statement plays the same role for the prepared transaction that COMMIT does for other transactions -- final conflict checking is done and the transaction becomes immune to later serialization_failure rollback. A transaction which starts after PREPARE TRANSACTION executes is not considered to overlap with the prepared transaction. In Jeff's example, if the Session2 runs a query before Session1 executes PREPARE TRANSACTION, one of them will fail. (I tested to make sure.) Does that sound sane, or is something else needed here? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
