On Dec14, 2010, at 21:18 , Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> In the process of re-verifying my serializable lock consistency patch, I ran
>> the fk_concurrency testsuite against *unpatched* HEAD for comparison.
>
>> My build of HEAD had asserts enabled, and I promptly triggered
>> Assert(!(tp.t_data->t_infomask & HEAP_XMAX_INVALID))
>> in heap_delete().
>
>> The seems wrong, if result was set to HeapTupleUpdated because the tuple was invisible
>> to the crosscheck snapshot, its xmax may very well be invalid.
>
> This patch seems certainly wrong. Please provide an actual test case
> rather than just asserting we should change this.
Running my FK concurrency test suite against HEAD as of today with 100 transaction / client triggers this within a few
secondsor so. The test suite can be found at https://github.com/fgp/fk_concurrency.
./fk_concurrency.sh <tx/client> native <path to pg> <host or patch to socket>
Could you explain what seems to be wrong with my patch? If you believe that it's impossible for a tuple to be visible
underthe query's snapshot but invisible to the crosscheck snapshot, unless it was deleted, that's *not* the case! For
RIchecks in serializable transactions, the *crosscheck* snapshot is the serializable snapshot, while the query's
snapshotis obtained with GetLatetsSnapshot(). This is the relevant snippet from ri_trigger.c, ri_PerformCheck():
if (IsolationUsesXactSnapshot() && detectNewRows) { CommandCounterIncrement(); /* be sure all my own work is
visible*/ test_snapshot = GetLatestSnapshot(); crosscheck_snapshot = GetTransactionSnapshot(); } else { /* the
defaultSPI behavior is okay */ test_snapshot = InvalidSnapshot; crosscheck_snapshot = InvalidSnapshot; }
best regards,
Florian Pflug