On Wed, Oct 6, 2021 at 2:45 PM Mark Dilger <mark.dilger@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
thebackend 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
inrecovery.
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
