Thread: 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.