1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00

A fix and a test case for Bug#26141 mixing table types in trigger

causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table 
will block on X lock unnecessarily (duplciate).
Code review fixes.

Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently, 
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table. 

If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently. 
The problem had other side-effects (see respective bug reports).

This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.

The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
This commit is contained in:
kostja@bodhi.(none)
2007-07-12 22:26:41 +04:00
parent 392b283f3d
commit 5ab4b6f1ac
18 changed files with 1255 additions and 58 deletions

View File

@ -82,3 +82,62 @@ ALICE 33 1 0
THE CROWN 43 1 0
THE PIE 53 1 1
drop table t1;
Bug#26141 mixing table types in trigger causes full
table lock on innodb table
Ensure we do not open and lock tables for the triggers we do not
fire.
drop table if exists t1, t2, t3;
drop trigger if exists trg_bug26141_au;
drop trigger if exists trg_bug26141_ai;
create table t1 (c int primary key) engine=innodb;
create table t2 (c int) engine=myisam;
create table t3 (c int) engine=myisam;
insert into t1 (c) values (1);
create trigger trg_bug26141_ai after insert on t1
for each row
begin
insert into t2 (c) values (1);
# We need the 'sync' lock to synchronously wait in connection 2 till
# the moment when the trigger acquired all the locks.
select release_lock("lock_bug26141_sync") into @a;
# 1000 is time in seconds of lock wait timeout -- this is a way
# to cause a manageable sleep up to 1000 seconds
select get_lock("lock_bug26141_wait", 1000) into @a;
end|
create trigger trg_bug26141_au after update on t1
for each row
begin
insert into t3 (c) values (1);
end|
select get_lock("lock_bug26141_wait", 0);
get_lock("lock_bug26141_wait", 0)
1
select get_lock("lock_bug26141_sync", /* must not be priorly locked */ 0);
get_lock("lock_bug26141_sync", /* must not be priorly locked */ 0)
1
insert into t1 (c) values (2);
select get_lock("lock_bug26141_sync", 1000);
get_lock("lock_bug26141_sync", 1000)
1
update t1 set c=3 where c=1;
select release_lock("lock_bug26141_sync");
release_lock("lock_bug26141_sync")
1
select release_lock("lock_bug26141_wait");
release_lock("lock_bug26141_wait")
1
select * from t1;
c
2
3
select * from t2;
c
1
select * from t3;
c
1
drop table t1, t2, t3;
End of 5.0 tests