Re: Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]

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