Commit 2900620e authored by John Esmet's avatar John Esmet

[t:3532] hit another test case - a thread with an open read transaction

on rows should not prevent another from grabbing write locks, since
no read locks should be taken


git-svn-id: file:///svn/mysql/tests/mysql-test@36507 c7de825b-a66e-492c-adef-691d508d4ae1
parent 7eda90e6
...@@ -28,6 +28,18 @@ ERROR HY000: Lock wait timeout exceeded; try restarting transaction ...@@ -28,6 +28,18 @@ ERROR HY000: Lock wait timeout exceeded; try restarting transaction
insert ignore t values (3); insert ignore t values (3);
ERROR HY000: Lock wait timeout exceeded; try restarting transaction ERROR HY000: Lock wait timeout exceeded; try restarting transaction
commit; commit;
begin;
select * from t;
a
1
2
3
select * from t for update;
a
1
2
3
commit;
drop table t; drop table t;
set global transaction isolation level repeatable read; set global transaction isolation level repeatable read;
set global tokudb_lock_timeout = 4000; set global tokudb_lock_timeout = 4000;
...@@ -33,6 +33,21 @@ insert ignore t values (3); ...@@ -33,6 +33,21 @@ insert ignore t values (3);
connection default; connection default;
commit; commit;
# further, if the main client has an open transaction
# reading the table, a second client should be able
# to grab write locks, since we're not supposed to
# be grabbing read locks.
connection default;
begin;
select * from t;
connection conn1;
select * from t for update;
# back to the main client, commit the transaction
connection default;
commit;
# cleanup # cleanup
drop table t; drop table t;
set global transaction isolation level repeatable read; set global transaction isolation level repeatable read;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment