On Mon, May 1, 2017 at 6:39 PM, Peter Geoghegan <p...@bowt.ie> wrote: > On Mon, May 1, 2017 at 6:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Maybe you can fix this by assuming that your own session's advertised xmin >> is a safe upper bound on everybody else's RecentGlobalXmin. But I'm not >> sure if that rule does what you want. > > That's what you might ultimately need to fall back on (that, or > perhaps repeated calls to GetOldestXmin() to recheck, in the style of > pg_visibility).
I spent only a few hours writing a rough prototype, and came up with something that does an IndexBuildHeapScan() scan following the existing index verification steps. Its amcheck callback does an index_form_tuple() call, hashes the resulting IndexTuple (heap TID and all), and tests it for membership of a bloom filter generated as part of the main B-Tree verification phase. The IndexTuple memory is freed immediately following hashing. The general idea here is that whatever IndexTuples ought to be in the index following a fresh REINDEX also ought to have been found in the index already. IndexBuildHeapScan() takes care of almost all of the details for us. I think I can do this correctly when only an AccessShareLock is acquired on heap + index, provided I also do a separate GetOldestXmin() before even the index scan begins, and do a final recheck of the saved GetOldestXmin() value against heap tuple xmin within the new IndexBuildHeapScan() callback (if we still think that it should have been found by the index scan, then actually throw a corruption related error). When there is only a ShareLock (for bt_parent_index_check() calls), the recheck isn't necessary. I think I should probably also make the IndexBuildHeapScan()-passed indexInfo structure "ii_Unique = false", since waiting for the outcome of a concurrent conflicting unique index insertion isn't useful, and can cause deadlocks. While I haven't really made my mind up, this design is extremely simple, and effectively tests IndexBuildHeapScan() at the same time as everything else. The addition of the bloom filter itself isn't trivial, but the code added to verify_nbtree.c is. The downside of going this way is that I cannot piggyback other types of heap verification on the IndexBuildHeapScan() scan. Still, perhaps it's worth it. Perhaps I should implement this bloom-filter-index-heap verification step as one extra option for the existing B-Tree verification functions. I may later add new verification functions that examine and verify the heap and related SLRUs alone. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
