mariadb/mysql-test/t/ndb_lock.test

-- source include/have_ndb.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 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;