> On Oct 6, 2021, at 12:28 PM, Peter Geoghegan <pg@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
notgoing 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
thatI did so, and then run pg_amcheck --relation=unlogged_relation, I'd rather get a complaint that I can't check an
unloggedrelation on a standby than get nothing. Sure, what I did doesn't make sense, but why should the application
paperover that mistake?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
