Erik Johnston <er...@element.io> writes: > We've also now found that the index on the backup does in fact point to > those ctids after all, but they are marked as dead. So at some point > between then and when we inserted the new row at that ctid today those > entries were marked undead.
I wonder if this behavior could be related to this 14.18 fix: https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=4934d3875 It probably isn't, because AFAICS that would only lead to transiently wrong answers --- but maybe you have a workload that occasionally hits that bug in the context of a query that will update and re-insert the recently-dead tuples? Still a bit far-fetched though, and if the index is actually corrupt this doesn't explain how it got that way. I'm more inclined to just say "once a btree index is out of order it can do some very strange things, both during inserts and searches". If you had some evidence about when and how the index became corrupt, it'd be worth studying that, but it sounds like you don't. regards, tom lane
