Peter Geoghegan <p...@bowt.ie> writes: > The difference with a test that could detect this variety of > corruption is that that would need to visit the heap, which tends to > be much larger than any one index, or even all indexes. That would > probably need to be random I/O, too. It might be possible to mostly > not visit the heap, though -- I'm not sure offhand. I'd have to study > the problem in detail, which I have no time for at the moment.
Unless I misunderstand this problem, the issue is that there might be some broken HOT chains, that is chains in which not all the heap tuples have the same values for the index columns, and in particular the live entry at the end of the chain doesn't agree with the index. It seems pretty impossible to detect that by examining the index alone. However, you might be able to find it without so much random I/O. I'm envisioning a seqscan over the table, in which you simply look for HOT chains in which the indexed columns aren't all the same. When you find one, you'd have to do a pretty expensive index lookup to confirm whether things are OK or not, but hopefully that'd be rare enough to not be a big performance sink. This seems like it'd be quite a different tool than amcheck, though. Also, it would only find broken-HOT-chain corruption, which might be a rare enough issue to not deserve a single-purpose tool. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers