On Wed, Oct 6, 2021 at 2:45 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > I think the disagreements are about something else.
Informally speaking, you could say that pg_amcheck and amcheck verify relations. More formally speaking, both amcheck (whether called by pg_amcheck or some other thing) can only prove the presence of corruption. They cannot prove its absence. (The amcheck docs have always said almost these exact words.) This seems to come up a lot because at various points you seem to be concerned about introducing specific imperfections. But it's not like your starting point was ever perfection, or ever could be. I can always describe a scenario in which amcheck misses real corruption -- a scenario which may be very contrived. So the mere fact that some new theoretical possibility of corruption is introduced by some action does not in itself mean much. We're dealing with that constantly, and always will be. Let's suppose I was to "directly fix amcheck + !indisvalid indexes". I don't even know what that means -- I honestly don't have a clue. You're focussing on one small piece of code in verify_nbtree.c, that seems to punt responsibility, but the fact is that there are deeply baked-in reasons why it does so. That's a reflection of how many things about the system work, in general. Attributing blame to any one small snippet of code (code in verify_nbtree.c, or wherever) just isn't helpful. > In truth, all the pg_amcheck frontend client can take a view on is whether it > was able to issue all the commands to the backend that it was asked to issue, > and whether any of those commands responded with an error. AFAICT that pg_amcheck has to do is follow the amcheck user docs, by generalizing from the example SQL query for the B-Tree stuff. And, it should separately filter non-temp relations for the heap stuff, for the same reasons (exactly the same situation there). > pg_amcheck -d db1 -d db2 -d db3 --table=mytable > > In this case, mytable is a regular table on db1, a temporary table on db2, > and an unlogged table on db3, and db3 is in recovery. I don't think that pg_amcheck needs to care about being in recovery, at all. I agreed with you about using pg_is_in_recovery() from at one point. That was a mistake on my part. > I thought that we were headed toward a decision where (despite my discomfort) > pg_amcheck would downgrade options as necessary, but now it sounds like > that's not so. So what should it do Downgrade is how you refer to it. I just think of it as making sure that pg_amcheck only asks amcheck to verify relations that are basically capable of being verified (e.g., not a temp table). -- Peter Geoghegan
