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-Wzm0NTsL_vAOTjoHixzj3_BMtF+6_x1U6ST3Ow7bJUtVWA@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>)
List pgsql-hackers
On Wed, Oct 6, 2021 at 10:57 AM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> > 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
typesthat cannot be checked because no checking functions for them exist.  (Hash, gin, gist, etc.)  On the other hand,
thereare relations which could be check but for the current state of the system, or could be checked in some particular
waybut for the current state of the system.  One of those has to do with code that doesn't exist, and the other has to
dowith the state of the system.  I'm only talking about the second. 

I specifically acknowledge and reject that distinction. That's my whole point.

Your words were: '--all no longer means "all relations" but rather
"all checkable relations"'. But somehow the original clean definition
of "--all" was made no less clean by not including GiST indexes and so
on from the start. You're asking me to believe that it was really
implied all along that "all checkable relations" didn't include the
relations that obviously weren't checkable. You're probably going to
have to keep making post-hoc amendments to your original statement
like this.

Obviously the gap in functionality from non-standard index AMs is far
more important than the totally theoretical issue with failed
CONCURRENTLY indexes. But even if they were equally important, your
emphasis on the latter would still be arbitrary.

> I totally disagree.  It is uncomfortable to me that `pg_amcheck --parent-check` will now silently not perform the
parentcheck that was explicitly requested. 

But the whole definition of "check that was explicitly requested"
relies on your existing understanding of what pg_amcheck is supposed
to do. That's not actually essential. I don't see it that way, for
example.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Role Self-Administration
Next
From: Mark Dilger
Date:
Subject: Re: Role Self-Administration