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