Re: [Maria-developers] MDEV-12620 - set lock_wait_timeout = 1; flush tables with read lock;
Hi, Sergey! On Jun 16, Sergey Vojtovich wrote:
revision-id: 056bab0880544d91ea67d18fe8db65b4f6625482 (mariadb-10.1.24-22-g056bab0) parent(s): 58f87a41bd8de7370cc05c41977fadc685826c9e committer: Sergey Vojtovich timestamp: 2017-06-16 15:47:46 +0400 message:
MDEV-12620 - set lock_wait_timeout = 1;flush tables with read lock; lock not released after timeout
Release GRL if FLUSH TABLES phase failed.
diff --git a/mysql-test/t/mdl_sync.test b/mysql-test/t/mdl_sync.test index 8e80978..c479c2a 100644 --- a/mysql-test/t/mdl_sync.test +++ b/mysql-test/t/mdl_sync.test @@ -4806,6 +4806,30 @@ disconnect con2; disconnect con3;
+--echo # +--echo # MDEV-12620 - set lock_wait_timeout = 1;flush tables with read lock; +--echo # lock not released after timeout +--echo # +CREATE TABLE t1(a INT) ENGINE=InnoDB; +SET debug_sync='open_tables_after_open_and_process_table SIGNAL ready WAIT_FOR go'; +send SELECT * FROM t1; + +connect (con1,localhost,root,,); +SET debug_sync='now WAIT_FOR ready'; +# lock_wait_timeout should be 0 in 10.3, so that we don't have to wait at all
what's special in 10.3?
+SET lock_wait_timeout=1; +--error ER_LOCK_WAIT_TIMEOUT +FLUSH TABLES WITH READ LOCK; +SET debug_sync='now SIGNAL go'; + +connection default; +reap; +SET debug_sync='RESET'; +DROP TABLE t1;
What should happen without a bug fix? DROP TABLE hangs?
+ +disconnect con1; + # Check that all connections opened by test cases in this file are really # gone so execution of other tests won't be affected by their presence. --source include/wait_until_count_sessions.inc diff --git a/sql/sql_reload.cc b/sql/sql_reload.cc index 376dfeb..d68ce96 100644 --- a/sql/sql_reload.cc +++ b/sql/sql_reload.cc @@ -253,7 +253,8 @@ bool reload_acl_and_cache(THD *thd, unsigned long long options, NOTE: my_error() has been already called by reopen_tables() within close_cached_tables(). */ - result= 1; + thd->global_read_lock.unlock_global_read_lock(thd); + return 1; }
Sure. Looks correct. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Sergei, On Fri, Jun 16, 2017 at 02:28:55PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
On Jun 16, Sergey Vojtovich wrote:
revision-id: 056bab0880544d91ea67d18fe8db65b4f6625482 (mariadb-10.1.24-22-g056bab0) parent(s): 58f87a41bd8de7370cc05c41977fadc685826c9e committer: Sergey Vojtovich timestamp: 2017-06-16 15:47:46 +0400 message:
MDEV-12620 - set lock_wait_timeout = 1;flush tables with read lock; lock not released after timeout
Release GRL if FLUSH TABLES phase failed.
diff --git a/mysql-test/t/mdl_sync.test b/mysql-test/t/mdl_sync.test index 8e80978..c479c2a 100644 --- a/mysql-test/t/mdl_sync.test +++ b/mysql-test/t/mdl_sync.test @@ -4806,6 +4806,30 @@ disconnect con2; disconnect con3;
+--echo # +--echo # MDEV-12620 - set lock_wait_timeout = 1;flush tables with read lock; +--echo # lock not released after timeout +--echo # +CREATE TABLE t1(a INT) ENGINE=InnoDB; +SET debug_sync='open_tables_after_open_and_process_table SIGNAL ready WAIT_FOR go'; +send SELECT * FROM t1; + +connect (con1,localhost,root,,); +SET debug_sync='now WAIT_FOR ready'; +# lock_wait_timeout should be 0 in 10.3, so that we don't have to wait at all
what's special in 10.3? Rev. 8026cd6202bd252dc9baac31d6c8bc39653bd637: ... Valid range of lock_wait_timeout and innodb_lock_wait_timeout was extended so that 0 is acceptable value (means no wait). ...
+SET lock_wait_timeout=1; +--error ER_LOCK_WAIT_TIMEOUT +FLUSH TABLES WITH READ LOCK; +SET debug_sync='now SIGNAL go'; + +connection default; +reap; +SET debug_sync='RESET'; +DROP TABLE t1;
What should happen without a bug fix? DROP TABLE hangs?
Yes, DROP TABLE hangs.
+ +disconnect con1; + # Check that all connections opened by test cases in this file are really # gone so execution of other tests won't be affected by their presence. --source include/wait_until_count_sessions.inc diff --git a/sql/sql_reload.cc b/sql/sql_reload.cc index 376dfeb..d68ce96 100644 --- a/sql/sql_reload.cc +++ b/sql/sql_reload.cc @@ -253,7 +253,8 @@ bool reload_acl_and_cache(THD *thd, unsigned long long options, NOTE: my_error() has been already called by reopen_tables() within close_cached_tables(). */ - result= 1; + thd->global_read_lock.unlock_global_read_lock(thd); + return 1; }
Sure. Looks correct.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Thanks, Sergey
participants (2)
-
Sergei Golubchik -
Sergey Vojtovich