Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, Andrey Borodin <x4mmm@yandex-team.ru>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Robert Haas <robertmhaas@gmail.com>, Петър Славов <pet.slavov@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-30T20:24:35Z
Lists: pgsql-bugs
On Mon, May 30, 2022 at 12:10 PM Andres Freund <andres@anarazel.de> wrote: > > 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. As long as it has a reasonably good chance of failing with the bug, it's still a valid test IMV. As you say, there may be some value in not over-specifying what the problem is -- that could actually bring unknown issues to light, especially if the test uses amcheck. Clearly there is never any strict guarantee that writing a test will avoid even one bug in the future. You're always working off some intuition about what related problems might happen in the future, weighed against the costs (mostly the added test cycles). And so adding an imprecise test really isn't very different to adding a precise test that reliably catches the bug that the test was written to catch. -- Peter Geoghegan
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