From 72e978828edb6b6cc045e6c728747dafd46b8732 Mon Sep 17 00:00:00 2001 From: Davi Arnaut Date: Fri, 3 Apr 2009 16:11:54 -0300 Subject: Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely The problem is that a SELECT .. FOR UPDATE statement might open a table and later wait for a impeding global read lock without noticing whether it is holding a table that is being waited upon the the flush phase of the process that took the global read lock. The same problem also affected the following statements: LOCK TABLES .. WRITE UPDATE .. SET (update and multi-table update) TRUNCATE TABLE .. LOAD DATA .. The solution is to make the above statements wait for a impending global read lock before opening the tables. If there is no impending global read lock, the statement raises a temporary protection against global read locks and progresses smoothly towards completion. Important notice: the patch does not try to address all possible cases, only those which are common and can be fixed unintrusively enough for 5.0. mysql-test/r/lock_multi.result: Add test case result for Bug#43230 mysql-test/t/lock_multi.test: Add test case for Bug#43230 sql/sql_lex.cc: Initialize flag. sql/sql_lex.h: Add a flag to the lexer. sql/sql_parse.cc: Wait for the global read lock is a write lock is going to be taken. The wait is done before opening tables. sql/sql_yacc.yy: Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES .. WRITE statement. --- sql/sql_lex.cc | 1 + 1 file changed, 1 insertion(+) (limited to 'sql/sql_lex.cc') diff --git a/sql/sql_lex.cc b/sql/sql_lex.cc index 4c53772bc25..da31106648a 100644 --- a/sql/sql_lex.cc +++ b/sql/sql_lex.cc @@ -204,6 +204,7 @@ void lex_start(THD *thd) lex->nest_level=0 ; lex->allow_sum_func= 0; lex->in_sum_func= NULL; + lex->protect_against_global_read_lock= FALSE; DBUG_VOID_RETURN; } -- cgit v1.2.1