On Dec14, 2010, at 21:18 , Tom Lane wrote: > Florian Pflug <f...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
