Isolation tests vs. SERIALIZABLE isolation level - Mailing list pgsql-hackers

From Tom Lane
Subject Isolation tests vs. SERIALIZABLE isolation level
Date
Msg-id 324309.1623722988@sss.pgh.pa.us
Whole thread Raw
Responses Re: Isolation tests vs. SERIALIZABLE isolation level  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Different compression methods for FPI
Next
From: Michael Paquier
Date:
Subject: Re: Different compression methods for FPI