> On Oct 6, 2021, at 10:39 AM, Peter Geoghegan <p...@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





Reply via email to