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

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Christophe Pettus <xof@thebuild.com>
Cc: Michael Paquier <michael@paquier.xyz>, Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-26T14:48:27Z
Lists: pgsql-bugs
On Thu, May 26, 2022 at 07:41:28AM -0700, Christophe Pettus wrote:
> 
> 
> > On May 26, 2022, at 07:40, Bruce Momjian <bruce@momjian.us> wrote:
> > 
> > Uh, if people don't know if they have used CREATE/REINDEX CONCURRENTLY
> > in PG 14.0+, they are going to need to run amcheck on all btree indexes
> > and reindex all non-btree indexes?  That is going to be a painful
> > message to deliver, and hear.  :-(
> 
> Unless we are 100% sure that amcheck will never return a false negative in this situation, we may have to recommend reindexing everything.  Ouch.

I assume we are then looking at reindexdb, which has a parallel option. 
I assume we can also recommend --concurrently on a patched PG 14.4,
which might not be terrible since it would not cause downtime.  I guess
the command would be:

	$ reindexdb --all --concurrently --jobs ##

Without reindexdb's features, this would be much more painful.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson




Commits

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

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