maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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@xxxxxxxxxxx