On Mon, Oct 4, 2021 at 4:28 PM Mark Dilger <mark.dil...@enterprisedb.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
