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

> On Oct 6, 2021, at 10:39 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> 
>> The differences in the upcoming version are
>> 
>> 1) --all no longer means "all relations" but rather "all checkable relations"
> 
> Clearly pg_amcheck never checked all relations, because it never
> checked indexes that are not B-Tree indexes. I'm pretty sure that I
> can poke big holes in almost any positivist statement like that with
> little effort.

There is a distinction here that you are (intentionally?) failing to acknowledge.  On the one hand, there are relation types that cannot be checked because no checking functions for them exist.  (Hash, gin, gist, etc.)  On the other hand, there are relations which could be check but for the current state of the system, or could be checked in some particular way but for the current state of the system.  One of those has to do with code that doesn't exist, and the other has to do with the state of the system.  I'm only talking about the second.

> 
>> 2) checking options should be automatically downgraded under circumstances where they cannot be applied
>> 3) unlogged relations during replication are by definition not corrupt
>> 
>> I think #1 and #3 are unsurprising enough that they need no documentation update.  #2 is slightly surprising (at least to me) so I updated the docs for it.
> 
> To me #2 sounds like a tautology. It could almost be phrased as
> "pg_amcheck does not check the things that it cannot check".

I totally disagree.  It is uncomfortable to me that `pg_amcheck --parent-check` will now silently not perform the parent check that was explicitly requested.  That reported an error before, and now it just downgrades the check.  This is hardly tautological.  I'm only willing to post a patch with that change because I can see a practical argument that somebody might run that as a cron job and they don't want the cron job failing when the database happens to go into recovery.  But again, not at all tautological.

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