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

> On Oct 6, 2021, at 12:28 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> I think that what I've said boils down to this:
>
> * pg_amcheck shouldn't attempt to verify temp relations, on the
> grounds that this is fundamentally not useful, and not something that
> could ever be sensibly interpreted as "just doing what the user asked
> for".

Right. I don't think there has been any disagreement on this. There is a bug in pg_amcheck with respect to this issue, and we all agree on that.

> * pg_amcheck calls to bt_index_check()/bt_index_parent_check() must
> only be made with "i.indisready AND i.indisvalid" indexes, just like
> the old query from the docs. (Actually, the same query also filters
> out temp relations -- which is why I view this issue as almost
> identical to the first.)
>
> Why would the user ask for something that fundamentally doesn't make
> any sense?

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.

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?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company