Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> Will look into that too. I'm not sure that adding extra expected
>> outputs is sane, though --- might be best to just force the intended
>> isolation level within those tests.
> As I recall (not much, admittedly) that was one of the options we
> considered in the old commit, but since the other isolation levels
> behaved differently we ageed that it was worth adding coverage for them.
> I don't know which ones are failing now; maybe forcing a specific
> isolation level is sufficient.
So the other one that fails for me is tuplelock-update, and a bit of
bisection testing confirms that it's never worked under serializable
isolation. The "expected" behavior in that case is unexciting --- all but
the s1 transaction just fail with "could not serialize access". So I'm
not convinced whether it's better to provide that as an expected output,
or to change the test to force a lower isolation level where it's testing
something useful. Anyway, that's your test case so I'll leave it to you
to do something with it.
> Clearly we should have done something to make sure these tests were run
> periodically with different isolation levels.
Yeah :-(. Both of these test cases have failed this scenario since
they were created.
regards, tom lane