> On Oct 6, 2021, at 12:28 PM, Peter Geoghegan <p...@bowt.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
