Feedback-ID: ia2694551:Fastmail
Date: Tue, 31 May 2022 16:54:34 +0200
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>,
	=?utf-8?B?0J/QtdGC0YrRgCDQodC70LDQstC+0LI=?= <pet.slavov@gmail.com>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17485: Records missing from Primary Key index when doing
 REINDEX INDEX CONCURRENTLY
Message-ID: <202205311454.n222v2nziqvt@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <202205311443.5xshc44kp7ll@alvherre.pgsql>
Archived-At: 
 <https://www.postgresql.org/message-id/202205311454.n222v2nziqvt%40alvherre.pgsql>
Precedence: bulk

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/