Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>, Andrey Borodin <x4mmm@yandex-team.ru>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Петър Славов <pet.slavov@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-30T20:51:25Z
Lists: pgsql-bugs 
On 2022-05-30 22:40:39 +0200, Alvaro Herrera wrote:
> On 2022-May-30, Andres Freund wrote:
> 
> > On 2022-05-30 15:54:08 +0900, Michael Paquier wrote:
> > > Yeah, I agree that we'd better revert c98763bf for the time being.
> > > And f9900df on top of that?
> > 
> > Well, f9900df needs to be reverted, because it caused the problem at hand, and
> > is ontop of c98763bf...
> 
> I'm not sure I understand what you're saying here.  I understood that
> both RIC and CIC are affected, so the reversal is of the following
> commits:

I was just a bit confused about Michael's phrasing of reverting f9900df "on
top of" c98763bf. Not important...


> c98763bf51bf Avoid spurious waits in concurrent indexing
> f9900df5f949 Avoid spurious wait in concurrent reindex
> d9d076222f5b VACUUM: ignore indexing operations with CONCURRENTLY

That looks right, yes.

Greetings,

Andres Freund

Commits

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

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