On Wed, Oct 6, 2021 at 12:36 PM Mark Dilger
<mark.dilger@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
notgoing 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
forgetthat I did so, and then run pg_amcheck --relation=unlogged_relation, I'd rather get a complaint that I can't
checkan unlogged relation on a standby than get nothing. Sure, what I did doesn't make sense, but why should the
applicationpaper 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
