Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY |
Дата | |
Msg-id | CAH2-Wz=mT7fWTuBNNXN4Mg7UbBueemJmoYz9JgPkZ39L6Rwmpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY (Andres Freund <andres@anarazel.de>) |
Список | 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
В списке pgsql-bugs по дате отправления: