Horton

Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Christophe Pettus <xof@thebuild.com>
Cc: Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>, Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Andrey Borodin <x4mmm@yandex-team.ru>, Петър Славов <pet.slavov@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-31T14:43:00Z
Lists: pgsql-bugs 
On 2022-May-26, Christophe Pettus wrote:

> Unless we are 100% sure that amcheck will never return a false
> negative in this situation, we may have to recommend reindexing
> everything.

I am not aware of any reason why amcheck would return a false negative.
Is there any evidence behind this assertion?

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).

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Commits

  1. Revert changes to CONCURRENTLY that "sped up" Xmin advance

  2. Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.