On 2022-May-31, Alvaro Herrera wrote:
> If there is none, the recommendation should be to use amcheck on all
> btree indexes and reindex those that have the problem; and reindex all
> indexes of other AMs that could have been reindexed or created
> concurrently in 14beta1 or later (implying: an index that was created in
> 13 and pg_upgraded but not touched afterwards is not at risk).
Another possibility for very large indexes may be to disable all types
of index scans, then apply no-op UPDATEs to the unindexed rows until the
migrate to some other heap block, then vacuum. After that, amcheck
should issue a clean report. This is much less intrusive than
reindexing possibly several TB of data.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
