On Sun, Nov 7, 2021 at 4:28 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> The index in one case is now 448 kB, in the other case is 632 kB, so I suspect
> they're due to this bug (for the 2nd one, a new index created from scratch with
> the same definition is 144 kB).
That seems quite likely. If you REINDEX, everything should be okay
(barring unique violations, perhaps).
> I tried looking for duplicate TIDs like this (which I wrote to search every
> suspect table before I found the above issue) - I'm not sure this is right,
> though.
The problem that we have with detecting this in amcheck is that it
doesn't detect duplicate TIDs, except when they happen to appear in
fully duplicate index tuples. In practice this means that amcheck has
a decent chance of detecting some problems, but cannot detect problems
caused by this particular bug reliably. Even with the heapallindexed
stuff.
> But this doesn't find any issue in that index. If I'm not wrong, "duplicate
> TIDs" are just one likely symptom of the bug, but not its only consequence.
> I donno how the TIDs can get out of order, though?
They don't. It's just that amcheck considers two adjacent duplicate
TIDs to involve a "misplaced TID" (in a posting list), which is just a
catch-all term. It's true that you could in theory see the same error
message with a posting list whose TIDs were in entirely the wrong
order, but there is no evidence that that ever happened as a result of
this bug -- and there is no reason to even suspect it. Not that it
makes that much difference, mind you -- corruption is corruption.
> I thought you might like to know about another instance of this in the wild.
> I'll disable those indexes and leave them around for a bit in case there's any
> question about them.
Thanks, but there is no further need for this.
--
Peter Geoghegan