[HACKERS] isolation tests broken for other than 'read committed'

2011-07-15 Thread Kevin Grittner
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:
 
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=846af54dd5a77dc02feeb5e34283608012cfb217
 
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



fk-deadlock_1.out
Description: Binary data


fk-deadlock2_1.out
Description: Binary data


fk-deadlock2_2.out
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] isolation tests broken for other than 'read committed'

2011-07-15 Thread Alvaro Herrera
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:
  
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=846af54dd5a77dc02feeb5e34283608012cfb217

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 alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers