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 seconds or 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 under the query's snapshot but invisible to the crosscheck snapshot, unless it was deleted, that's *not* the case! For RI checks in serializable transactions, the *crosscheck* snapshot is the serializable snapshot, while the query's snapshot is 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 default SPI behavior is okay */
    test_snapshot = InvalidSnapshot;
    crosscheck_snapshot = InvalidSnapshot;
  }

best regards,
Florian Pflug