"Florian G. Pflug" <fgp@phlo.org> writes:
> Tom Lane wrote:
>> Here is another variant of the risk scenario:
>>
>> 1. Xact A is running (in Read Committed mode).
>> 2. Xact C's GetSnapshotData reads next transaction ID into xmax, then is
>> swapped out before it can acquire ProcArrayLock.
>> 3. Xact B gets new XID (>= C's xmax), makes changes and commits.
>> 4. Xact A changes some row R changed by xact B and commits.
>> 5. Xact C finishes getting its snapshot data. It sees xact A as done,
>> but sees xact B as still running (since B >= xmax).
>>
>> Now C will see R changed by xact B and then xact A, *but* does not see
>> other changes made by xact B. If C is supposed to be in Serializable mode,
>> this is wrong.
> I never really grasped why we need to assume serializable here - this seems
> wrong if C is read-committed too. Seeing only half of a transaction's changes
> can never be right, can it?
You'd be surprised ;-) ... Read Committed is not totally consistent,
even considering a single statement using a single snapshot, because of
the rules about UPDATEs starting from the latest committed version.
But let's not get into that today.
Anyway, one thing I realized while making this text is that the example
cases mentioned in CommitTransaction and GetSnapshotData really were
basically the same case. The difference is that in this case, the
failure to see B as committed is closely related to the way that xmax is
computed. We could get rid of this example if we switched over to your
LatestCompletedXid proposal.
> I had a rather hard time understanding these things initially - at least
> for me, the enlightenment came when I realized that most of the locking
> in there actually ensures that (T1) holds - or in other words, that
> the relation "A sees B as committed" *has* to be a transitive one.
> So I'd like to see this reasoning in that README - though maybe I'm the
> only one to whom this is the clearest wording...
I'll put some of this into the README.
regards, tom lane
