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

> On Oct 6, 2021, at 1:49 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>
>> The analogy here is: are we trying to verify that the relations are
>> valid? Or are we just trying to verify that they are as valid as we
>> can expect them to be?
>
> I think that we do the latter (or something much closer to the latter
> than to the former). It's actually a very Karl Popper thing. Absence
> of evidence isn't evidence of absence -- period. We can get into a
> conversation about degrees of confidence, but that doesn't seem like
> it'll ever affect how we go about designing these things.
>
> A lot of my disagreements around this stuff (especially with Mark)
> seem to stem from this basic understanding of things, in one way or
> another.

I think the disagreements are about something else.

Talking about pg_amcheck "checking" a database, or "checking" a relation, is actually short-hand for saying that
pg_amcheckhanded off the objects to amcheck's functions.  The pg_amcheck client application itself isn't checking
anything. This short-hand leads to misunderstandings that makes it really hard for me to understand what people mean in
thisthread. Your comments suggest that I (or pg_amcheck) take some view on whether the database is corrupt, or whether
we'veproven that it is corrupt, or whether we've proven that it is not corrupt.  In truth, all the pg_amcheck frontend
clientcan take a view on is whether it was able to issue all the commands to the backend that it was asked to issue,
andwhether any of those commands responded with an error. 

Talking about pg_amcheck "failing" is also confusing.  I don't understand what people mean by this.  The example
towardsthe top of this thread from Alexander was about pg_amcheck || echo "fail", but that suggests that failure is
justa question of whether pg_amcheck exited with non-zero exit code.  In other parts of the thead, talking about
pg_amcheck"failing" seems to be used to mean "pg_amcheck has diagnosed corruption".  This all gets muddled together. 

Upthread, I decided to just make the changes to pg_amcheck that you seemed to want, but now I don't know what you want.
Can you opine on each of the following.  I need to know what they should print, and whether they should return with a
non-zeroexit status.  I genuinely can't post a patch until I know what these are supposed to do, because I need to
updatethe regression tests accordingly:  


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.


pg_amcheck --all --index="*accounting*" --parent-check --table="*human_resources*" --table="*peter*"
--relation="*alexander*"

Assume a multitude of databases, some primary, some standby, some indexes logged, some unlogged, some temporary.  Some
ofthe human resources tables are unlogged, some not, and they're scattered across different databases, some in
recovery,some not.  There is exactly one table per database that matches the pattern /*peter*/, but it's circumstances
aredifferent from one database to the next, and likewise for the pattern /*alexander*/ except that in some databases it
matchesan index and in others it matches a table. 


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 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company