isolation tests broken for other than 'read committed'
It's been a few days since I've run through my usual builds and
tests, and I just discovered that part of my routine was broken by
this commit:
The isolation tests are broken when run against a database with
default_transaction_isolation = 'repeatable read' or 'serializable'.
(Which is ironic, really.)
Adding the attached files to src/test/isolation/expected/ causes
those stricter isolation levels to work in my tests so far, but I
get random failures in 'read committed' due to apparent randomness
in which process is chosen as the deadlock victim. I seem to
remember Noah mentioning this and a suggested fix, but the problem
in manifest in a current checkout of head.
Of course, another approach to this would be to set transaction
isolation level in the new tests. If we do that, we might want to
create tests at all three levels, for completeness.
-Kevin
Import Notes
Reference msg id not found: 4E207748020000250003F3CC@gw.wicourts.govReference msg id not found: 4E20777E020000250003F3D2@gw.wicourts.gov
Excerpts from Kevin Grittner's message of vie jul 15 18:23:10 -0400 2011:
It's been a few days since I've run through my usual builds and
tests, and I just discovered that part of my routine was broken by
this commit:
Sorry 'bout that.
The isolation tests are broken when run against a database with
default_transaction_isolation = 'repeatable read' or 'serializable'.
(Which is ironic, really.)Adding the attached files to src/test/isolation/expected/ causes
those stricter isolation levels to work in my tests so far, but I
get random failures in 'read committed' due to apparent randomness
in which process is chosen as the deadlock victim. I seem to
remember Noah mentioning this and a suggested fix, but the problem
in manifest in a current checkout of head.
Yeah, the patch I committed from Noah should fix the issues in read
committed. It hadn't crossed my mind that I need to manually set the
level to serializable in order for the tests to be meaningful :-(
Shouldn't we be running the tests three times with the different useful
isolation levels?
Of course, another approach to this would be to set transaction
isolation level in the new tests. If we do that, we might want to
create tests at all three levels, for completeness.
I think your approach of adding alternative expected outputs makes more
sense.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support