From 3395c53efcf07126fdf05ccd4ffdafb8ce319751 Mon Sep 17 00:00:00 2001 From: unknown Date: Wed, 16 May 2007 09:51:05 +0400 Subject: A fix and a test case for Bug#21483 "Server abort or deadlock on INSERT DELAYED with another implicit insert" Also fixes and adds test cases for bugs: 20497 "Trigger with INSERT DELAYED causes Error 1165" 21714 "Wrong NEW.value and server abort on INSERT DELAYED to a table with a trigger". Post-review fixes. Problem: In MySQL INSERT DELAYED is a way to pipe all inserts into a given table through a dedicated thread. This is necessary for simplistic storage engines like MyISAM, which do not have internal concurrency control or threading and thus can not achieve efficient INSERT throughput without support from SQL layer. DELAYED INSERT works as follows: For every distinct table, which can accept DELAYED inserts and has pending data to insert, a dedicated thread is created to write data to disk. All user connection threads that attempt to delayed-insert into this table interact with the dedicated thread in producer/consumer fashion: all records to-be inserted are pushed into a queue of the dedicated thread, which fetches the records and writes them. In this design, client connection threads never open or lock the delayed insert table. This functionality was introduced in version 3.23 and does not take into account existence of triggers, views, or pre-locking. E.g. if INSERT DELAYED is called from a stored function, which, in turn, is called from another stored function that uses the delayed table, a deadlock can occur, because delayed locking by-passes pre-locking. Besides: * the delayed thread works directly with the subject table through the storage engine API and does not invoke triggers * even if it was patched to invoke triggers, if triggers, in turn, used other tables, the delayed thread would have to open and lock involved tables (use pre-locking). * even if it was patched to use pre-locking, without deadlock detection the delayed thread could easily lock out user connection threads in case when the same table is used both in a trigger and on the right side of the insert query: the delayed thread would not release locks until all inserts are complete, and user connection can not complete inserts without having locks on the tables used on the right side of the query. Solution: These considerations suggest two general alternatives for the future of INSERT DELAYED: * it is considered a full-fledged alternative to normal INSERT * it is regarded as an optimisation that is only relevant for simplistic engines. Since we missed our chance to provide complete support of new features when 5.0 was in development, the first alternative currently renders infeasible. However, even the second alternative, which is to detect new features and convert DELAYED insert into a normal insert, is not easy to implement. The catch-22 is that we don't know if the subject table has triggers or is a view before we open it, and we only open it in the delayed thread. We don't know if the query involves pre-locking until we have opened all tables, and we always first create the delayed thread, and only then open the remaining tables. This patch detects the problematic scenarios and converts DELAYED INSERT to a normal INSERT using the following approach: * if the statement is executed under pre-locking (e.g. from within a stored function or trigger) or the right side may require pre-locking, we detect the situation before creating a delayed insert thread and convert the statement to a conventional INSERT. * if the subject table is a view or has triggers, we shutdown the delayed thread and convert the statement to a conventional INSERT. mysql-test/r/insert.result: Update test results. mysql-test/t/insert.test: Add a test case for Bug#21483, Bug#20497, Bug#21714 (INSERT DELAYED and stored routines, triggers). sql/sp_head.cc: Upgrade lock type to TL_WRITE when computing the pre-locking set. sql/sql_base.cc: Use a new method. sql/sql_insert.cc: INSERT DELAYED and pre-locking: - if under pre-locking, upgrade the lock type to TL_WRITE and proceed as a normal write - if DELAYED table has triggers, also request a lock upgrade. - make sure errors in the delayed thread are propagated correctly sql/sql_lex.h: Add a method to check if a parsed tree refers to stored routines. --- mysql-test/t/insert.test | 139 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) (limited to 'mysql-test/t/insert.test') diff --git a/mysql-test/t/insert.test b/mysql-test/t/insert.test index 0a8e184ea5c..76177403bd0 100644 --- a/mysql-test/t/insert.test +++ b/mysql-test/t/insert.test @@ -216,3 +216,142 @@ select * from t1; drop view v1; drop table t1,t2; + +# +# BUG#21483: Server abort or deadlock on INSERT DELAYED with another +# implicit insert +# +# The solution is to downgrade INSERT DELAYED to normal INSERT if the +# statement uses functions and access tables or triggers, or is called +# from a function or a trigger. +# +--disable_warnings +DROP TABLE IF EXISTS t1; +DROP FUNCTION IF EXISTS f1; +DROP FUNCTION IF EXISTS f2; +--enable_warnings + +CREATE TABLE t1 (i INT); +delimiter |; +CREATE FUNCTION f1() RETURNS INT +BEGIN + INSERT INTO t1 VALUES (1); + RETURN 1; +END | +CREATE FUNCTION f2() RETURNS INT +BEGIN + INSERT DELAYED INTO t1 VALUES (2); + RETURN 1; +END | +delimiter ;| + +SELECT f1(); +SELECT f2(); +INSERT INTO t1 VALUES (3); +INSERT DELAYED INTO t1 VALUES (4); + +--error ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG +INSERT INTO t1 VALUES (f1()); + +--error ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG +INSERT DELAYED INTO t1 VALUES (f1()); + +--error ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG +INSERT INTO t1 VALUES (f2()); + +--error ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG +INSERT DELAYED INTO t1 VALUES (f2()); + +CREATE TRIGGER t1_bi BEFORE INSERT ON t1 FOR EACH ROW + INSERT INTO t1 VALUES (NEW.i); + +--error ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG +INSERT INTO t1 VALUES (1); + +--error ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG +INSERT DELAYED INTO t1 VALUES (1); + +SELECT * FROM t1; + +DROP FUNCTION f2; +DROP FUNCTION f1; +DROP TABLE t1; + +# +# BUG#20497: Trigger with INSERT DELAYED causes Error 1165 +# +# Fixed by the patch for Bug#21483 +# +--disable_warnings +DROP TABLE IF EXISTS t1, t2; +--enable_warnings + +CREATE TABLE t1 (i INT); +CREATE TABLE t2 (i INT); + +CREATE TRIGGER t1_bi BEFORE INSERT ON t1 FOR EACH ROW + INSERT DELAYED INTO t2 VALUES (NEW.i); + +CREATE TRIGGER t1_bu BEFORE UPDATE ON t1 FOR EACH ROW + INSERT DELAYED INTO t2 VALUES (NEW.i); + +CREATE TRIGGER t1_bd BEFORE DELETE ON t1 FOR EACH ROW + INSERT DELAYED INTO t2 VALUES (OLD.i); + +INSERT INTO t1 VALUES (1); +INSERT DELAYED INTO t1 VALUES (2); +SELECT * FROM t1; +UPDATE t1 SET i = 3 WHERE i = 1; +SELECT * FROM t1; +DELETE FROM t1 WHERE i = 3; +SELECT * FROM t1; +SELECT * FROM t2; + +DROP TABLE t1, t2; + +# +# BUG#21714: Wrong NEW.value and server abort on INSERT DELAYED to a +# table with a trigger +# +# Fixed by the patch for Bug#21483 +# +--disable_warnings +DROP TABLE IF EXISTS t1, t2; +--enable_warnings + +CREATE TABLE t1 (i INT); +CREATE TRIGGER t1_bi BEFORE INSERT ON t1 FOR EACH ROW + SET @a= NEW.i; + +SET @a= 0; +INSERT DELAYED INTO t1 VALUES (1); +SELECT @a; +INSERT DELAYED INTO t1 VALUES (2); +SELECT @a; + +DROP TABLE t1; + +CREATE TABLE t1 (i INT); +CREATE TABLE t2 (i INT); + +CREATE TRIGGER t1_ai AFTER INSERT ON t1 FOR EACH ROW + INSERT INTO t2 VALUES (NEW.i); + +CREATE TRIGGER t1_au AFTER UPDATE ON t1 FOR EACH ROW + INSERT DELAYED INTO t2 VALUES (NEW.i); + +CREATE TRIGGER t1_ad AFTER DELETE ON t1 FOR EACH ROW + INSERT DELAYED INTO t2 VALUES (OLD.i); + +INSERT DELAYED INTO t1 VALUES (1); +SELECT * FROM t1; +UPDATE t1 SET i = 2 WHERE i = 1; +SELECT * FROM t1; +DELETE FROM t1 WHERE i = 2; +SELECT * FROM t1; +SELECT * FROM t2; + +DROP TABLE t1, t2; + +--echo End of 5.0 tests. + -- cgit v1.2.1