On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both Dan and I realized that these were dependent on the assumption that SSI's commitSeqNo is assigned in the order in which the transactions became visible.
This comment in the patch actually suggests a stronger requirement:
+ * For correct SERIALIZABLE semantics, the commitSeqNo must appear to be set + * atomically with the work of the transaction becoming visible to other + * transactions.
So, is it enough for the commitSeqNos to be set in the order the transactions become visible to others? I'm assuming 'yes' for now, as the approach being discussed to assign commitSeqNo in ProcArrayEndTransaction() without also holding SerializableXactHashLock is not going to work otherwise, and if I understood correctly you didn't see any correctness issue with that. Please shout if I'm missing something.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
