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
