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: Michael Paquier <michael@paquier.xyz>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-30T19:10:04Z
Lists: pgsql-bugs 
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 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.

I think it's ok if we have a heuristic test for this kind of thing. It
sometimes can even be good, because it means we'll get different schedulings
over time, hitting "unknown" bugs.

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.