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

On Mon, Oct 4, 2021 at 4:28 PM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> I am concerned about giving the user the false impression that an index (or table) was checked when it was not. I don't see the logic in
>
> pg_amcheck -i idx1 -i idx2 -i idx3
>
> skipping all three indexes and then reporting success.

This is the first time that anybody mentioned the -i option on the
thread. I read your previous remarks as making a very broad statement,
about every single issue.

Anyway, the issue with -i doesn't seem like it changes that much. Why
not just behave as if there is no such "visible" index? That's the
same condition, for all practical purposes. If that approach doesn't
seem good enough, then the error message can be refined to make the
user aware of the specific issue.

> What if the user launches the pg_amcheck command precisely because they see error messages in the logs during a long running reindex command, and are curious if the index so generated is corrupt.

I'm guessing that you meant REINDEX CONCURRENTLY.

Since you're talking about the case where it has an error, the whole
index build must have failed. So the user would get exactly what
they'd expect -- verification of the original index, without any
hindrance from the new/failed index.

(Thinks for a moment...)

Actually, I think that we'd only verify the original index, even
before the error with CONCURRENTLY (though I've not checked that point
myself).

--
Peter Geoghegan