On Wed, Oct 6, 2021 at 12:36 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > The user may not know that the system has changed. > > For example, if I see errors in the logs suggesting corruption in a relation > named "mark" and run pg_amcheck --relation=mark, I expect that to check the > relation. If that relation is a temporary table, I'd like to know that it's > not going to be checked, not just have pg_amcheck report that everything is > ok.
This is just a detail to me. I agree that it's reasonable to say "I can't do that specific thing you asked for with the temp relation", instead of "no such verifiable relation" -- but only because it's more specific and user friendly. Providing a slightly friendlier error message like this does not actually conflict with the idea of generally treating temp relations as "not visible to pg_amcheck". Ditto for the similar !indisready/!i.indisvalid B-Tree case. > As another example, if I change my environment variables to connect to the > standby rather than the primary, and forget that I did so, and then run > pg_amcheck --relation=unlogged_relation, I'd rather get a complaint that I > can't check an unlogged relation on a standby than get nothing. Sure, what I > did doesn't make sense, but why should the application paper over that > mistake? I think that it shouldn't get an error at all -- this should be treated like an empty relation, per the verify_nbtree.c precedent. pg_amcheck doesn't need to concern itself with this at all. -- Peter Geoghegan
