On 21.06.2011 05:18, Dan Ports wrote:
> The first patch addresses this bug by re-adding SXACT_FLAG_ROLLED_BACK,
> in a more limited form than its previous incarnation.
>
> We need to be able to distinguish transactions that have already
> called ReleasePredicateLocks and are thus eligible for cleanup from
> those that have been merely marked for abort by other
> backends. Transactions that are ROLLED_BACK are excluded from
> SxactGlobalXmin calculations, but those that are merely DOOMED need to
> be included.
>
> Also update a couple of assertions to ensure we only try to clean up
> ROLLED_BACK transactions.
Thanks, committed.
> The second patch fixes a bug in PreCommit_CheckForSerializationFailure.
> This function checks whether there's a dangerous structure of the form
> far ---> near ---> me
> where neither the "far" or "near" transactions have committed. If so,
> it aborts the "near" transaction by marking it as DOOMED. However, that
> transaction might already be PREPARED. We need to check whether that's
> the case and, if so, abort the transaction that's trying to commit
> instead.
Yep, committed. All the other places where we set the DOOMED flag seem
to handle that already.
In the long term, I'm not sure this is the best way to handle this. It
feels a bit silly to set the flag, release the SerializableXactHashLock,
and reacquire it later to remove the transaction from the hash table.
Surely that could be done in some more straightforward way. But I don't
feel like fiddling with it this late in the release cycle.
> One of the prepared_xacts regression tests actually hits this bug.
> I removed the anomaly from the duplicate-gids test so that it fails in
> the intended way, and added a new test to check serialization failures
> with a prepared transaction.
Hmm, I have ran "make installcheck" with
default_transaction_isolation='serializable' earlier. I wonder why I
didn't see that.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com