mirror of
https://github.com/MariaDB/server.git
synced 2025-01-21 22:34:18 +01:00
6ceacd4fb9
FOR UPDATE is causing a lock". This patch tries to address problems which were exposed during backporting of original patch to 5.1 tree. - It ensures that we don't change locking behavior of simple SELECT statements on InnoDB tables when they are executed under LOCK TABLES ... READ and with @@innodb_table_locks=0. Also we no longer pass TL_READ_DEFAULT/TL_WRITE_DEFAULT lock types, which are supposed to be parser-only, to handler::start_stmt() method. - It makes check_/no_concurrent_insert.inc auxiliary scripts more robust against changes in test cases that use them and also ensures that they don't unnecessarily change environment of caller.
91 lines
2 KiB
Text
91 lines
2 KiB
Text
set global innodb_table_locks=1;
|
|
select @@innodb_table_locks;
|
|
@@innodb_table_locks
|
|
1
|
|
drop table if exists t1;
|
|
set @@innodb_table_locks=1;
|
|
create table t1 (id integer, x integer) engine=INNODB;
|
|
insert into t1 values(0, 0);
|
|
set autocommit=0;
|
|
SELECT * from t1 where id = 0 FOR UPDATE;
|
|
id x
|
|
0 0
|
|
set autocommit=0;
|
|
lock table t1 write;
|
|
update t1 set x=1 where id = 0;
|
|
select * from t1;
|
|
id x
|
|
0 1
|
|
commit;
|
|
update t1 set x=2 where id = 0;
|
|
commit;
|
|
unlock tables;
|
|
select * from t1;
|
|
id x
|
|
0 2
|
|
commit;
|
|
drop table t1;
|
|
#
|
|
# Old lock method (where LOCK TABLE was ignored by InnoDB) no longer
|
|
# works when LOCK TABLE ... WRITE is used due to fix for bugs #46272
|
|
# "MySQL 5.4.4, new MDL: unnecessary and bug #37346 "innodb does not
|
|
# detect deadlock between update and alter table". But it still works
|
|
# for LOCK TABLE ... READ.
|
|
#
|
|
set @@innodb_table_locks=0;
|
|
create table t1 (id integer primary key, x integer) engine=INNODB;
|
|
insert into t1 values(0, 0),(1,1),(2,2);
|
|
commit;
|
|
SELECT * from t1 where id = 0 FOR UPDATE;
|
|
id x
|
|
0 0
|
|
# Connection 'con2'.
|
|
set autocommit=0;
|
|
set @@innodb_table_locks=0;
|
|
# The following statement should block because SQL-level lock
|
|
# is taken on t1 which will wait until concurrent transaction
|
|
# is commited.
|
|
# Sending:
|
|
lock table t1 write;;
|
|
# Connection 'con1'.
|
|
# Wait until LOCK TABLE is blocked on SQL-level lock.
|
|
# We should be able to do UPDATEs and SELECTs within transaction.
|
|
update t1 set x=1 where id = 0;
|
|
select * from t1;
|
|
id x
|
|
0 1
|
|
1 1
|
|
2 2
|
|
# Unblock LOCK TABLE.
|
|
commit;
|
|
# Connection 'con2'.
|
|
# Reap LOCK TABLE.
|
|
unlock tables;
|
|
# Connection 'con1'.
|
|
select * from t1 where id = 0 for update;
|
|
id x
|
|
0 1
|
|
# Connection 'con2'.
|
|
# The below statement should not be blocked as LOCK TABLES ... READ
|
|
# does not take strong SQL-level lock on t1. SELECTs which do not
|
|
# conflict with transaction in the first connections should not be
|
|
# blocked.
|
|
lock table t1 read;
|
|
select * from t1;
|
|
id x
|
|
0 1
|
|
1 1
|
|
2 2
|
|
select * from t1 where id = 1 lock in share mode;
|
|
id x
|
|
1 1
|
|
unlock tables;
|
|
select * from t1;
|
|
id x
|
|
0 1
|
|
1 1
|
|
2 2
|
|
commit;
|
|
# Connection 'con1'.
|
|
commit;
|
|
drop table t1;
|