Thread

SSI atomic commit

Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-07-05T17:03:52Z

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.  There is a race condition such that this is not
necessarily true.  It is a very narrow race condition, which would
come up very rarely in practice, but Murphy's Law being what it is,
I think we need to consider it a bug and fix it.
 
We considered a fix which would be contained within predicate.c code
and operate by making pessimistic assumptions, so that no false
negatives occurred.  The reason we didn't go that way is that the
code would be very convoluted and fragile.  The attached patch just
makes it atomic in a very direct way, and adjusts the predicate.c
code to use the right tests in the right places.  We were careful
not to add any LW locking to the path that a normal transaction
without an XID is terminating, since there had obviously been
significant work put into keeping locks out of that code path.
 
Dan and I collaborated on this code over the holiday weekend, and
are in agreement that this is the right route.  I know it's only six
days before beta3, but I'm hopeful that someone can review this for
commit in time to make it into that beta.
 
This patch applies over the top of the fix for the 2PC permutation
problems.
 
I apologize for having found this bug so late in the release cycle.
 
-Kevin