On Mon, Jun 18, 2018 at 4:05 PM, Peter Geoghegan <p...@bowt.ie> wrote: > IOW, the approach you've taken in bttargetdelete() isn't quite correct > because you imagine that it's okay to occasionally "lose" the index > tuple that you originally found, and just move on. That needs to be > 100% reliable, or else we'll end up with index tuples that point to > the wrong heap tuples in rare cases with concurrent insertions.
Attached patch adds a new amcheck check within bt_index_parent_check(). With the patch, heap TIDs are accumulated in a tuplesort and sorted at the tail end of verification (before optional heapallindexed verification runs). This will reliably detect the kind of corruption I noticed was possible with your patch. Note that the amcheck enhancement that went along with my heap-tid-btree-sort patch may not have detected this issue, which is why I wrote this patch -- the heap-tid-btree-sort amcheck stuff could detect duplicates, but only when all other attributes happened to be identical when comparing sibling index tuples (i.e. only when we must actually compare TIDs across sibling index tuples). If you add this check, I'm pretty sure that you can detect any possible problem. You should think about using this to debug your patch. I may get around to submitting this to a CF, but that isn't a priority right now. -- Peter Geoghegan
0001-Detect-duplicate-heap-TIDs-using-a-tuplesort.patch
Description: Binary data
