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
-
Revert changes to CONCURRENTLY that "sped up" Xmin advance
- e28bb8851969 15.0 landed
- 042b584c7f7d 14.4 landed
-
Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.
- 18b87b201f73 15.0 cited