Re: BUG #17949: Adding an index introduces serialisation anomalies.
От | Thomas Munro |
---|---|
Тема | Re: BUG #17949: Adding an index introduces serialisation anomalies. |
Дата | |
Msg-id | CA+hUKGKOqpuHx_tx7qpbTX4o49YnCFrnB2uE3B+PUy03bBTPBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17949: Adding an index introduces serialisation anomalies. (Artem Anisimov <artem.anisimov.255@gmail.com>) |
Список | pgsql-bugs |
On Sat, Jul 15, 2023 at 1:05 AM Artem Anisimov <artem.anisimov.255@gmail.com> wrote: > thank you for the fixes. I've looked up the patches in pg's git repo, > and they got me wondering: where is the repo with pg tests? I'd be > really uneasy to make changes to concurrency-related code without a > decent testsuite to verify them. Generally, the tests for SSI are in: https://git.postgresql.org/gitweb/?p=postgresql.git;a=tree;f=src/test/isolation/specs ... and see also ../expected. Typically they are created as features are developed, but we'll add new tests to cover complicated bugfixes if we can see how to do it. There are also non-SSI related tests in there because the "isolation" infrastructure turned out to be so useful. For the problems discovered in this thread, I couldn't see how to do it. These required unlucky scheduling to go wrong -- whereas the existing test infrastructure is based on deterministic behaviour with wait points at the statement level. It has been suggested before that we could perhaps have a way to insert test-harness-controlled waitpoints. But even if we had such infrastructure, the relevant wait points are actually gone after the fixes (ie the window where you have to do something in another thread to cause problems has been closed so there is no candidate wait point left). Such infrastructure might have been useful for demonstrating the bugs deterministically while the windows existed. One of the basic techniques we often use when trying to understand what is going on in such cases is to insert sleeps into interesting places to widen windows and make failures "almost" deterministic, as I did for one of the cases here. I suppose we could in theory have a suite of 'high load' tests of a more statistical nature that could include things like the repro you sent in. It would burn a whole bunch of CPU trying to break complicated concurrency stuff in ways that have been known to be broken in the past. I'm not sure it's worth it though. Sometimes it's OK for tests to be temporarily useful, too...
В списке pgsql-bugs по дате отправления: