-- source include/have_ndb.inc -- source include/have_binlog_format_row.inc -- source include/not_embedded.inc connect (con1,localhost,root,,); connect (con2,localhost,root,,); --disable_warnings DROP TABLE IF EXISTS t1,t2,t3,t4,t5,t6,t7; --enable_warnings # # Transaction lock test to show that the NDB # table handler is working properly with # transaction locks # # # Testing of scan isolation # connection con1; create table t1 (x integer not null primary key, y varchar(32)) engine = ndb; insert into t1 values (1,'one'), (2,'two'); select * from t1 order by x; connection con2; select * from t1 order by x; connection con1; start transaction; insert into t1 values (3,'three'); select * from t1 order by x; connection con2; start transaction; select * from t1 order by x; connection con1; commit; connection con2; select * from t1 order by x; commit; drop table t1; ### # Bug#6020 create table t1 (pk integer not null primary key, u int not null, o int not null, unique(u), key(o)) engine = ndb; insert into t1 values (1,1,1), (2,2,2), (3,3,3), (4,4,4), (5,5,5); lock tables t1 write; delete from t1 where pk = 1; unlock tables; select * from t1 order by pk; insert into t1 values (1,1,1); lock tables t1 write; delete from t1 where u = 1; unlock tables; select * from t1 order by pk; insert into t1 values (1,1,1); lock tables t1 write; delete from t1 where o = 1; unlock tables; select * from t1 order by pk; insert into t1 values (1,1,1); drop table t1; # Lock for update create table t1 (x integer not null primary key, y varchar(32), z integer, key(z)) engine = ndb; insert into t1 values (1,'one',1); # PK access connection con1; begin; select * from t1 where x = 1 for update; connection con2; begin; --error 1205 select * from t1 where x = 1 for update; rollback; connection con1; rollback; insert into t1 values (2,'two',2),(3,"three",3); begin; select * from t1 where x = 1 for update; connection con2; --error 1205 select * from t1 where x = 1 for update; select * from t1 where x = 2 for update; rollback; connection con1; commit; # table scan # # Note that there are two distinct execution paths in which we unlock # non-matching rows inspected during table scan - one that is used in # case of filesort and one that used in rest of cases. Below we cover # the latter (Bug #20390 "SELECT FOR UPDATE does not release locks of # untouched rows in full table scans"). connection con1; begin; # We can't use "order by x" here as it will cause filesort --replace_column 1 # 2 # 3 # select * from t1 where y = 'one' or y = 'three' for update; connection con2; begin; # Have to check with pk access here since scans take locks on # all rows and then release them in chunks select * from t1 where x = 2 for update; --error 1205 select * from t1 where x = 1 for update; rollback; connection con1; commit; # And now the test for case with filesort begin; select * from t1 where y = 'one' or y = 'three' order by x for update; connection con2; begin; select * from t1 where x = 2 for update; --error 1205 select * from t1 where x = 1 for update; rollback; connection con1; commit; # index scan connection con1; begin; select * from t1 where z > 1 and z < 3 for update; connection con2; begin; # Have to check with pk access here since scans take locks on # all rows and then release them in chunks select * from t1 where x = 1 for update; --error 1105,1205 select * from t1 where x = 2 for update; rollback; connection con1; commit; # share locking # PK access connection con1; begin; select * from t1 where x = 1 lock in share mode; connection con2; begin; select * from t1 where x = 1 lock in share mode; select * from t1 where x = 2 for update; --error 1205 select * from t1 where x = 1 for update; rollback; connection con1; commit; # table scan connection con1; begin; # We can't use "order by x" here as it will cause filesort --replace_column 1 # 2 # 3 # select * from t1 where y = 'one' or y = 'three' lock in share mode; connection con2; begin; select * from t1 where y = 'one' lock in share mode; # Have to check with pk access here since scans take locks on # all rows and then release them in chunks select * from t1 where x = 2 for update; --error 1205 select * from t1 where x = 1 for update; rollback; connection con1; commit; # And the same test for case with filesort connection con1; begin; select * from t1 where y = 'one' or y = 'three' order by x lock in share mode; connection con2; begin; select * from t1 where y = 'one' lock in share mode; select * from t1 where x = 2 for update; --error 1205 select * from t1 where x = 1 for update; rollback; connection con1; commit; # index scan connection con1; begin; select * from t1 where z > 1 and z < 3 lock in share mode; connection con2; begin; select * from t1 where z = 1 lock in share mode; # Have to check with pk access here since scans take locks on # all rows and then release them in chunks select * from t1 where x = 1 for update; --error 1205 select * from t1 where x = 2 for update; rollback; connection con1; commit; drop table t1; # End of 4.1 tests # # Bug #17812 Previous lock table for write causes "stray" lock # although table is recreated # # this creating, locking, and dropping causes a subsequent hang # on the delete below waiting for table t2 the locking in the # "other" connection is relevant, as without it there is no problem # connection con1; create table t3 (id2 int) engine=ndb; connection con2; lock tables t3 write; unlock tables; connection con1; drop table t3; connection con1; create table t2 (id int, j int) engine=ndb; insert into t2 values (2, 2); create table t3 (id int) engine=ndb; connection con2; lock tables t3 read; connection con1; # here we get a hang before bugfix although we shouldn't delete t2 from t2, t3 where t2.id = t3.id; connection con2; unlock tables; connection con1; drop table t2, t3;