Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> That looks like a reasonable state to me, but I'm not sure exactly
> what the design calls for. I am guessing that the real problem is
> in PreCommit_CheckForSerializationFailure(), where there are 6
> conditions that must be met for an error to be thrown. T2 falls
> out right away at condition 1. T1 falls out on condition 4. I
> don't really understand condition 4 at all -- can you explain it?
> And can you explain conditions 5 and 6 too?
Since most transactions are rolled back on a conflict detection
during a read or write attempt, there are only a few very specific
conditions which can "slip through" to where they need to be
detected on commit. Here's the code with the six conditions:
if (MySerializableXact->inConflict != InvalidSerializableXact
&& MySerializableXact->inConflict != MySerializableXact
&& !(MySerializableXact->inConflict->rolledBack)
&& MySerializableXact->inConflict->inConflict !=
InvalidSerializableXact
&& !SxactIsCommitted(MySerializableXact->inConflict)
&& !SxactIsCommitted(MySerializableXact->inConflict->inConflict))
Condition 4 is testing whether MySerializableXact is on the "out"
side of a pivot -- in the parlance of most examples, is
MySerializableXact TN?
Condition 5 and 6 confirm that neither T0 nor T1 have committed
first; we can only have a problem if TN commits first.
Basically, when we already have a pivot, but no transaction has yet
committed, we wait to see if TN commits first. If so, we have a
problem; if not, we don't. There's probably some room for improving
performance by cancelling T0 or T1 instead of TN, at least some of
the time; but in this pass we are always cancelling the transaction
in whose process we detect the need to cancel something.
-Kevin