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

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

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, 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-30T14:11:39Z
Lists: pgsql-bugs
On 2022-May-30, Michael Paquier wrote:

> > Was there anything else running on the system? c98763bf51bf also needs to
> > reverted, of course.
> 
> Yeah, I agree that we'd better revert c98763bf for the time being.
> And f9900df on top of that?

Yeah, both commits need to be reverted, since the latter depends
critically on the former.  I'll get the revert pushed soon.

> I was trying to think of ways to get an isolation test out of that,
> but that proves to be sort of tricky as we need to manipulate the HOT
> chains after the validation phase has begun with the snapshot from the
> build phase.  It is easy to block before the validation transaction
> starts, like in WaitForLockersMultiple() beforehand, though.

Hmm.  I suppose for the next try of implementing a feature like this,
we'll definitely want to incorporate some tests that can catch problems
of this sort.  But I don't think we need to come up with something right
now.

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