Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 6, 2021, at 1:49 PM, Peter Geoghegan <pg(at)bowt(dot)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_amcheck handed 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 this thread. Your comments suggest that I (or pg_amcheck) take some view on whether the database is corrupt, or whether we've proven that it is corrupt, or whether we've proven that it is not corrupt. 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.

Talking about pg_amcheck "failing" is also confusing. I don't understand what people mean by this. The example towards the top of this thread from Alexander was about pg_amcheck || echo "fail", but that suggests that failure is just a 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-zero exit status. I genuinely can't post a patch until I know what these are supposed to do, because I need to update the 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 of the 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 are different from one database to the next, and likewise for the pattern /*alexander*/ except that in some databases it matches an 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