Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
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-31T01:45:04Z
Lists: pgsql-bugs
On Mon, May 30, 2022 at 12:10:04PM -0700, Andres Freund wrote: > 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. Yeah, the tricky part is how to parametize that to be cheap, still useful. Having a larger number of attributes makes the particular problem of this thread easier to hit because it enlarges the validation window in the concurrent build, and generating such dummy data with a simple schema should be quick enough, but I would not accept in the tree a test that takes ~5s to run without a rather good hit rate. For this particular issue, I would say that something able to fail up to 20%~25% of the time for a short run-time would be quite decent, actually, even if that sounds low in a single run because the odds of detecting one failure increase a "lot" after a few repeated runs. On my own laptop, the original test of the reporter takes up to 3~4s to reproduce the issue, for example, all the time, so that's good :) -- Michael
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