Isolation tests vs. SERIALIZABLE isolation level
In the past people have tried to ensure that the isolation tests
would pass regardless of the prevailing default_transaction_isolation
setting. (That was sort of the point, in fact, for the earliest
tests using that infrastructure.)
This seems to have been forgotten about lately, as all of these tests
fail with default_transaction_isolation = serializable:
test detach-partition-concurrently-1 ... FAILED 504 ms
test detach-partition-concurrently-3 ... FAILED 2224 ms
test detach-partition-concurrently-4 ... FAILED 1600 ms
test fk-partitioned-2 ... FAILED 133 ms
test lock-update-delete ... FAILED 538 ms
test tuplelock-update ... FAILED 10223 ms
test tuplelock-upgrade-no-deadlock ... FAILED 664 ms
test tuplelock-partition ... FAILED 49 ms
(drop-index-concurrently-1 also failed until just now, but
I resurrected its variant expected-file.)
So:
* Do we still care about that policy?
* If so, who's going to fix the above-listed problems?
* Should we try to get some routine testing of this case
in place?
regards, tom lane
On Tue, Jun 15, 2021 at 2:09 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
* Do we still care about that policy?
* If so, who's going to fix the above-listed problems?
* Should we try to get some routine testing of this case
in place?
I wondered the same in commit 37929599 (the same problem for
src/test/regress, which now passes but only in master, not the back
branches). I doubt it will find real bugs very often, and I doubt
many people would enjoy the slowdown if it were always on, but it
might make sense to have something like PG_TEST_EXTRA that can be used
to run the tests at all three levels, and then turn that on in a few
strategic places like CI and a BF animal or two.