Re: BUG #17212: pg_amcheck fails on checking temporary relations - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: BUG #17212: pg_amcheck fails on checking temporary relations
Date
Msg-id CAH2-WznaYWowxxFaGK6Hv=SUQYS2-r7dQZJFWyDT_W6GGtuCjA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17212: pg_amcheck fails on checking temporary relations  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: BUG #17212: pg_amcheck fails on checking temporary relations  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
On Wed, Oct 6, 2021 at 9:25 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> Thanks for reviewing!
>
> I expect to post a new version shortly.

Not sure how much it matters, but I have some thoughts on the return
value of pg_amcheck. (I'm mostly going into this now because it seems
related to how we discuss these issues generally.)

A return value of 0 cannot be said to indicate that the database is
not corrupt; strictly speaking the verification process doesn't
actually verify anything. The null hypothesis is that the database
isn't corrupt. pg_amcheck looks for disconfirmatory evidence (evidence
of corruption) on a best-effort basis. This seems fundamental.

If this philosophy of science stuff seems too abstract, then I can be
more concrete: pg_amcheck doesn't even attempt to verify indexes that
aren't B-Tree indexes. Clearly we cannot be sure that the database
contains no corruption when there happens to be even one such index.
And yet the return value from pg_amcheck is still 0 (barring problems
elsewhere). I think that it'll always be possible to make *some*
argument like that, even in a world where pg_amcheck + amcheck are
very feature complete. As I said, it seems fundamental.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Running tests under valgrind is getting slower at an alarming pace
Next
From: Mark Dilger
Date:
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations