- commits - lists.mariadb.org

[Commits] 84b928b9ed1: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic'
by sujatha 02 May '19

02 May '19

revision-id: 84b928b9ed112a92c03c7aa06431fc8f9a7a1f2f (mariadb-10.2.23-100-g84b928b9ed1) parent(s): 810f014ca7a705381e110cb26649c528bc00f179 author: Sujatha Sivakumar committer: Sujatha Sivakumar timestamp: 2019-05-02 17:08:54 +0530 message: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic' Problem: ======== The test now fails with the following trace: CURRENT_TEST: rpl.rpl_parallel_temptable --- /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.result +++ /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.reject @@ -194,7 +194,6 @@ 30 conservative 31 conservative 32 optimistic -33 optimistic Analysis: ========= The part of test which fails with result content mismatch is given below. CREATE TEMPORARY TABLE t4 (a INT PRIMARY KEY) ENGINE=InnoDB; INSERT INTO t4 VALUES (32); INSERT INTO t4 VALUES (33); INSERT INTO t1 SELECT a, "optimistic" FROM t4; slave_parallel_mode=optimistic The expectation of the above test script is, INSERT FROM SELECT should read both 32, 33 and populate table 't1'. But this expectation fails occasionally. All three INSERT statements are handed over to three different slave parallel workers. Temporary tables are not safe for parallel replication. They were designed to be visible to one thread only, so have no table locking. Thus there is no protection against two conflicting transactions committing in parallel and things like that. So anything that uses temporary tables will be serialized with anything before it, when using parallel replication by using a "wait_for_prior_commit" function call. This will ensure that the each transaction is executed sequentially. But there exists a code path in which the above wait doesn't happen. Because of this at times INSERT from SELECT doesn't wait for the INSERT (33) to complete and it completes its executes and enters commit stage. Hence only row 32 is found in those cases resulting in test failure. The wait needs to be added within "open_temporary_table" call. The code looks like this within "open_temporary_table". Each thread tries to open temporary table in 3 different ways: case 1: Find a temporary table which is already in use by using find_temporary_table(tl) && wait_for_prior_commit() case 2: If above failed then try to look for temporary table which is marked for free for reuse. This internally calls "wait_for_prior_commit()" if table is found. find_and_use_tmp_table(tl, &table) case 3: If none of the above open a new table handle from table share. if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); } At present the "wait_for_prior_commit" happens only in case 1 & 2. Fix: ==== Add a call for "wait_for_prior_commit" for case 3. --- sql/temporary_tables.cc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sql/temporary_tables.cc b/sql/temporary_tables.cc index ed23dae06d2..da938db00f9 100644 --- a/sql/temporary_tables.cc +++ b/sql/temporary_tables.cc @@ -369,6 +369,19 @@ bool THD::open_temporary_table(TABLE_LIST *tl) if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); + /* + Temporary tables are not safe for parallel replication. They were + designed to be visible to one thread only, so have no table locking. + Thus there is no protection against two conflicting transactions + committing in parallel and things like that. + + So for now, anything that uses temporary tables will be serialised + with anything before it, when using parallel replication. + */ + if (table && rgi_slave && + rgi_slave->is_parallel_exec && + wait_for_prior_commit()) + DBUG_RETURN(true); } if (!table)

1 0

[Commits] 84b928b9ed1: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic'
by sujatha 02 May '19

02 May '19

revision-id: 84b928b9ed112a92c03c7aa06431fc8f9a7a1f2f (mariadb-10.2.23-100-g84b928b9ed1) parent(s): 810f014ca7a705381e110cb26649c528bc00f179 author: Sujatha Sivakumar committer: Sujatha Sivakumar timestamp: 2019-05-02 17:08:54 +0530 message: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic' Problem: ======== The test now fails with the following trace: CURRENT_TEST: rpl.rpl_parallel_temptable --- /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.result +++ /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.reject @@ -194,7 +194,6 @@ 30 conservative 31 conservative 32 optimistic -33 optimistic Analysis: ========= The part of test which fails with result content mismatch is given below. CREATE TEMPORARY TABLE t4 (a INT PRIMARY KEY) ENGINE=InnoDB; INSERT INTO t4 VALUES (32); INSERT INTO t4 VALUES (33); INSERT INTO t1 SELECT a, "optimistic" FROM t4; slave_parallel_mode=optimistic The expectation of the above test script is, INSERT FROM SELECT should read both 32, 33 and populate table 't1'. But this expectation fails occasionally. All three INSERT statements are handed over to three different slave parallel workers. Temporary tables are not safe for parallel replication. They were designed to be visible to one thread only, so have no table locking. Thus there is no protection against two conflicting transactions committing in parallel and things like that. So anything that uses temporary tables will be serialized with anything before it, when using parallel replication by using a "wait_for_prior_commit" function call. This will ensure that the each transaction is executed sequentially. But there exists a code path in which the above wait doesn't happen. Because of this at times INSERT from SELECT doesn't wait for the INSERT (33) to complete and it completes its executes and enters commit stage. Hence only row 32 is found in those cases resulting in test failure. The wait needs to be added within "open_temporary_table" call. The code looks like this within "open_temporary_table". Each thread tries to open temporary table in 3 different ways: case 1: Find a temporary table which is already in use by using find_temporary_table(tl) && wait_for_prior_commit() case 2: If above failed then try to look for temporary table which is marked for free for reuse. This internally calls "wait_for_prior_commit()" if table is found. find_and_use_tmp_table(tl, &table) case 3: If none of the above open a new table handle from table share. if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); } At present the "wait_for_prior_commit" happens only in case 1 & 2. Fix: ==== Add a call for "wait_for_prior_commit" for case 3. --- sql/temporary_tables.cc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sql/temporary_tables.cc b/sql/temporary_tables.cc index ed23dae06d2..da938db00f9 100644 --- a/sql/temporary_tables.cc +++ b/sql/temporary_tables.cc @@ -369,6 +369,19 @@ bool THD::open_temporary_table(TABLE_LIST *tl) if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); + /* + Temporary tables are not safe for parallel replication. They were + designed to be visible to one thread only, so have no table locking. + Thus there is no protection against two conflicting transactions + committing in parallel and things like that. + + So for now, anything that uses temporary tables will be serialised + with anything before it, when using parallel replication. + */ + if (table && rgi_slave && + rgi_slave->is_parallel_exec && + wait_for_prior_commit()) + DBUG_RETURN(true); } if (!table)

1 0

[Commits] 84b928b9ed1: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic'
by sujatha 02 May '19

02 May '19

revision-id: 84b928b9ed112a92c03c7aa06431fc8f9a7a1f2f (mariadb-10.2.23-100-g84b928b9ed1) parent(s): 810f014ca7a705381e110cb26649c528bc00f179 author: Sujatha Sivakumar committer: Sujatha Sivakumar timestamp: 2019-05-02 17:08:54 +0530 message: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic' Problem: ======== The test now fails with the following trace: CURRENT_TEST: rpl.rpl_parallel_temptable --- /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.result +++ /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.reject @@ -194,7 +194,6 @@ 30 conservative 31 conservative 32 optimistic -33 optimistic Analysis: ========= The part of test which fails with result content mismatch is given below. CREATE TEMPORARY TABLE t4 (a INT PRIMARY KEY) ENGINE=InnoDB; INSERT INTO t4 VALUES (32); INSERT INTO t4 VALUES (33); INSERT INTO t1 SELECT a, "optimistic" FROM t4; slave_parallel_mode=optimistic The expectation of the above test script is, INSERT FROM SELECT should read both 32, 33 and populate table 't1'. But this expectation fails occasionally. All three INSERT statements are handed over to three different slave parallel workers. Temporary tables are not safe for parallel replication. They were designed to be visible to one thread only, so have no table locking. Thus there is no protection against two conflicting transactions committing in parallel and things like that. So anything that uses temporary tables will be serialized with anything before it, when using parallel replication by using a "wait_for_prior_commit" function call. This will ensure that the each transaction is executed sequentially. But there exists a code path in which the above wait doesn't happen. Because of this at times INSERT from SELECT doesn't wait for the INSERT (33) to complete and it completes its executes and enters commit stage. Hence only row 32 is found in those cases resulting in test failure. The wait needs to be added within "open_temporary_table" call. The code looks like this within "open_temporary_table". Each thread tries to open temporary table in 3 different ways: case 1: Find a temporary table which is already in use by using find_temporary_table(tl) && wait_for_prior_commit() case 2: If above failed then try to look for temporary table which is marked for free for reuse. This internally calls "wait_for_prior_commit()" if table is found. find_and_use_tmp_table(tl, &table) case 3: If none of the above open a new table handle from table share. if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); } At present the "wait_for_prior_commit" happens only in case 1 & 2. Fix: ==== Add a call for "wait_for_prior_commit" for case 3. --- sql/temporary_tables.cc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sql/temporary_tables.cc b/sql/temporary_tables.cc index ed23dae06d2..da938db00f9 100644 --- a/sql/temporary_tables.cc +++ b/sql/temporary_tables.cc @@ -369,6 +369,19 @@ bool THD::open_temporary_table(TABLE_LIST *tl) if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); + /* + Temporary tables are not safe for parallel replication. They were + designed to be visible to one thread only, so have no table locking. + Thus there is no protection against two conflicting transactions + committing in parallel and things like that. + + So for now, anything that uses temporary tables will be serialised + with anything before it, when using parallel replication. + */ + if (table && rgi_slave && + rgi_slave->is_parallel_exec && + wait_for_prior_commit()) + DBUG_RETURN(true); } if (!table)

1 0

[Commits] 84b928b9ed1: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic'
by sujatha 02 May '19

02 May '19

revision-id: 84b928b9ed112a92c03c7aa06431fc8f9a7a1f2f (mariadb-10.2.23-100-g84b928b9ed1) parent(s): 810f014ca7a705381e110cb26649c528bc00f179 author: Sujatha Sivakumar committer: Sujatha Sivakumar timestamp: 2019-05-02 17:08:54 +0530 message: MDEV-19076: rpl_parallel_temptable result mismatch '-33 optimistic' Problem: ======== The test now fails with the following trace: CURRENT_TEST: rpl.rpl_parallel_temptable --- /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.result +++ /mariadb/10.4/mysql-test/suite/rpl/r/rpl_parallel_temptable.reject @@ -194,7 +194,6 @@ 30 conservative 31 conservative 32 optimistic -33 optimistic Analysis: ========= The part of test which fails with result content mismatch is given below. CREATE TEMPORARY TABLE t4 (a INT PRIMARY KEY) ENGINE=InnoDB; INSERT INTO t4 VALUES (32); INSERT INTO t4 VALUES (33); INSERT INTO t1 SELECT a, "optimistic" FROM t4; slave_parallel_mode=optimistic The expectation of the above test script is, INSERT FROM SELECT should read both 32, 33 and populate table 't1'. But this expectation fails occasionally. All three INSERT statements are handed over to three different slave parallel workers. Temporary tables are not safe for parallel replication. They were designed to be visible to one thread only, so have no table locking. Thus there is no protection against two conflicting transactions committing in parallel and things like that. So anything that uses temporary tables will be serialized with anything before it, when using parallel replication by using a "wait_for_prior_commit" function call. This will ensure that the each transaction is executed sequentially. But there exists a code path in which the above wait doesn't happen. Because of this at times INSERT from SELECT doesn't wait for the INSERT (33) to complete and it completes its executes and enters commit stage. Hence only row 32 is found in those cases resulting in test failure. The wait needs to be added within "open_temporary_table" call. The code looks like this within "open_temporary_table". Each thread tries to open temporary table in 3 different ways: case 1: Find a temporary table which is already in use by using find_temporary_table(tl) && wait_for_prior_commit() case 2: If above failed then try to look for temporary table which is marked for free for reuse. This internally calls "wait_for_prior_commit()" if table is found. find_and_use_tmp_table(tl, &table) case 3: If none of the above open a new table handle from table share. if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); } At present the "wait_for_prior_commit" happens only in case 1 & 2. Fix: ==== Add a call for "wait_for_prior_commit" for case 3. --- sql/temporary_tables.cc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sql/temporary_tables.cc b/sql/temporary_tables.cc index ed23dae06d2..da938db00f9 100644 --- a/sql/temporary_tables.cc +++ b/sql/temporary_tables.cc @@ -369,6 +369,19 @@ bool THD::open_temporary_table(TABLE_LIST *tl) if (!table && (share= find_tmp_table_share(tl))) { table= open_temporary_table(share, tl->get_table_name(), true); + /* + Temporary tables are not safe for parallel replication. They were + designed to be visible to one thread only, so have no table locking. + Thus there is no protection against two conflicting transactions + committing in parallel and things like that. + + So for now, anything that uses temporary tables will be serialised + with anything before it, when using parallel replication. + */ + if (table && rgi_slave && + rgi_slave->is_parallel_exec && + wait_for_prior_commit()) + DBUG_RETURN(true); } if (!table)

1 0

[Commits] 1380efa28e5: Merge branch '5.5' into 10.1
by Oleksandr Byelkin 02 May '19

02 May '19

revision-id: 1380efa28e59bee9a76fdd8f84397fdecd42ac85 (mariadb-10.1.38-158-g1380efa28e5) parent(s): ca94ce2a5817cec6d402b6c92653330825e0a2bf aba911542641c93553bad0307021983998042d69 author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2019-05-02 09:23:39 +0200 message: Merge branch '5.5' into 10.1 mysql-test/t/bootstrap.test | 9 +++++++++ sql/sql_base.cc | 3 +-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --cc mysql-test/t/bootstrap.test index 8508c6c9dc6,5494a2d4154..879d42be2d6 --- a/mysql-test/t/bootstrap.test +++ b/mysql-test/t/bootstrap.test @@@ -65,53 -66,13 +65,62 @@@ SELECT 'bug' as '' FROM INFORMATION_SCH --error 1 --exec $MYSQLD_BOOTSTRAP_CMD --myisam_recover_options=NONE + # + # MDEV-19349 mysql_install_db: segfault at tmp_file_prefix check + # + --write_file $MYSQLTEST_VARDIR/tmp/1 + use test; + EOF + --exec $MYSQLD_BOOTSTRAP_CMD < $MYSQLTEST_VARDIR/tmp/1 >> $MYSQLTEST_VARDIR/tmp/bootstrap.log 2>&1 + --remove_file $MYSQLTEST_VARDIR/tmp/1 + --echo End of 5.5 tests + +--source include/not_windows_embedded.inc +--source include/have_example_plugin.inc +# +# Check that --bootstrap can install and uninstall plugins +# +let $PLUGIN_DIR=`select @@plugin_dir`; +--write_file $MYSQLTEST_VARDIR/tmp/install_plugin.sql +install soname 'ha_example'; +uninstall plugin unusable; +EOF +--exec $MYSQLD_BOOTSTRAP_CMD --plugin-dir=$PLUGIN_DIR < $MYSQLTEST_VARDIR/tmp/install_plugin.sql >> $MYSQLTEST_VARDIR/tmp/bootstrap.log 2>&1 +--remove_file $MYSQLTEST_VARDIR/tmp/install_plugin.sql + +# +# Check that installed plugins are *not* automatically loaded in --bootstrap +# +--write_file $MYSQLTEST_VARDIR/tmp/bootstrap_plugins.sql +SET SQL_MODE=""; +use test; +create table t1(a int) engine=example charset=latin1; +EOF +--exec $MYSQLD_BOOTSTRAP_CMD --plugin-dir=$PLUGIN_DIR < $MYSQLTEST_VARDIR/tmp/bootstrap_plugins.sql >> $MYSQLTEST_VARDIR/tmp/bootstrap.log 2>&1 +--remove_file $MYSQLTEST_VARDIR/tmp/bootstrap_plugins.sql +flush tables; +show create table t1; +drop table t1; +--replace_result .dll .so +select * from mysql.plugin; +truncate table mysql.plugin; + + +# +# MDEV-9969 mysql_install_db error processing ignore_db_dirs. +# +--write_file $MYSQLTEST_VARDIR/tmp/bootstrap_9969.sql +use test; +EOF +--exec $MYSQLD_BOOTSTRAP_CMD --ignore-db-dirs='some_dir' --ignore-db-dirs='some_dir' < $MYSQLTEST_VARDIR/tmp/bootstrap_9969.sql >> $MYSQLTEST_VARDIR/tmp/bootstrap.log 2>&1 +--remove_file $MYSQLTEST_VARDIR/tmp/bootstrap_9969.sql + +# +# MDEV-13397 MariaDB upgrade fail when using default_time_zone +# +--write_file $MYSQLTEST_VARDIR/tmp/bootstrap_9969.sql +use test; +EOF +--exec $MYSQLD_BOOTSTRAP_CMD --default-time-zone=Europe/Moscow < $MYSQLTEST_VARDIR/tmp/bootstrap_9969.sql >> $MYSQLTEST_VARDIR/tmp/bootstrap.log 2>&1 +--remove_file $MYSQLTEST_VARDIR/tmp/bootstrap_9969.sql

1 0

[Commits] 2b7e080: MDEV-19363 Assertion `select_lex' failed in LEX::pop_select
by IgorBabaev 02 May '19

02 May '19

revision-id: 2b7e080faece853f463f6f546066d54e1cbc330b (mariadb-10.4.4-61-g2b7e080) parent(s): ea679c88c323dc2c79d9b5c05d4dba9671ad62bc author: Igor Babaev committer: Igor Babaev timestamp: 2019-05-01 18:20:06 -0700 message: MDEV-19363 Assertion `select_lex' failed in LEX::pop_select This patch corrects the patch for MDEV-19324. The latter did not work properly in the cases when the transformation (SELECT ... ORDER BY ...) LIMIT ... => SELECT ... ORDER BY ... LIMIT ... was applied to the operands of a set operation. --- mysql-test/main/brackets.result | 59 +++++++++++++++++++++++++++++++++++++++++ mysql-test/main/brackets.test | 15 +++++++++++ sql/sql_lex.cc | 8 +++--- 3 files changed, 79 insertions(+), 3 deletions(-) diff --git a/mysql-test/main/brackets.result b/mysql-test/main/brackets.result index 3cf3468..869afe5 100644 --- a/mysql-test/main/brackets.result +++ b/mysql-test/main/brackets.result @@ -393,4 +393,63 @@ EXPLAIN } } drop table t1; +# +# MDEV-19363: ((SELECT ...) ORDER BY col ) LIMIT n UNION ... +# +create table t1 (pk int); +insert into t1 values (5),(4),(1),(2),(3); +((select * from t1 order by pk) limit 2) union (select * from t1 where pk > 4); +pk +1 +2 +5 +explain extended ((select * from t1 order by pk) limit 2) union (select * from t1 where pk > 4); +id select_type table type possible_keys key key_len ref rows filtered Extra +1 PRIMARY t1 ALL NULL NULL NULL NULL 5 100.00 Using filesort +2 UNION t1 ALL NULL NULL NULL NULL 5 100.00 Using where +NULL UNION RESULT <union1,2> ALL NULL NULL NULL NULL NULL NULL +Warnings: +Note 1003 (/* select#1 */ select `test`.`t1`.`pk` AS `pk` from `test`.`t1` order by `test`.`t1`.`pk` limit 2) union (/* select#2 */ select `test`.`t1`.`pk` AS `pk` from `test`.`t1` where `test`.`t1`.`pk` > 4) +explain format=json ((select * from t1 order by pk) limit 2) union (select * from t1 where pk > 4); +EXPLAIN +{ + "query_block": { + "union_result": { + "table_name": "<union1,2>", + "access_type": "ALL", + "query_specifications": [ + { + "query_block": { + "select_id": 1, + "read_sorted_file": { + "filesort": { + "sort_key": "t1.pk", + "table": { + "table_name": "t1", + "access_type": "ALL", + "rows": 5, + "filtered": 100 + } + } + } + } + }, + { + "query_block": { + "select_id": 2, + "operation": "UNION", + "table": { + "table_name": "t1", + "access_type": "ALL", + "rows": 5, + "filtered": 100, + "attached_condition": "t1.pk > 4" + } + } + } + ] + } + } +} +drop table t1; # End of 10.4 tests diff --git a/mysql-test/main/brackets.test b/mysql-test/main/brackets.test index 54f7d27..cf1dcc5 100644 --- a/mysql-test/main/brackets.test +++ b/mysql-test/main/brackets.test @@ -139,5 +139,20 @@ eval explain format=json $q2; drop table t1; +--echo # +--echo # MDEV-19363: ((SELECT ...) ORDER BY col ) LIMIT n UNION ... +--echo # + +create table t1 (pk int); +insert into t1 values (5),(4),(1),(2),(3); + +let $q= +((select * from t1 order by pk) limit 2) union (select * from t1 where pk > 4); +eval $q; +eval explain extended $q; +eval explain format=json $q; + +drop table t1; + --echo # End of 10.4 tests diff --git a/sql/sql_lex.cc b/sql/sql_lex.cc index 66ac69f..e1a6420 100644 --- a/sql/sql_lex.cc +++ b/sql/sql_lex.cc @@ -9147,13 +9147,15 @@ SELECT_LEX *LEX::parsed_select(SELECT_LEX *sel, Lex_order_limit_lock * l) } else { - SELECT_LEX_UNIT *unit= create_unit(sel); - if (!unit) - return NULL; if (!l->order_list && !sel->explicit_limit) l->order_list= &sel->order_list; else + { + SELECT_LEX_UNIT *unit= create_unit(sel); + if (!unit) + return NULL; sel= wrap_unit_into_derived(unit); + } if (!sel) return NULL; l->set_to(sel);

1 0

[Commits] 4383265ccbb: Adjusting sql_command to align with higher version, this is an adjustment
by Varun 01 May '19

01 May '19

revision-id: 4383265ccbbd7bb7339f3f79faf84a28a2b51120 (mariadb-10.1.38-155-g4383265ccbb) parent(s): 5b035c84567b60c2ca680de96f5179a6dd3d9e61 author: Varun Gupta committer: Varun Gupta timestamp: 2019-05-01 01:19:30 +0530 message: Adjusting sql_command to align with higher version, this is an adjustment to the patch for MDEV-17605 --- sql/sql_show.cc | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/sql/sql_show.cc b/sql/sql_show.cc index 7f0c50a2e55..d8b35eda089 100644 --- a/sql/sql_show.cc +++ b/sql/sql_show.cc @@ -4272,8 +4272,8 @@ fill_schema_table_by_open(THD *thd, bool is_show_fields_or_keys, SQLCOM_SHOW_FIELDS is used because it satisfies 'only_view_structure()'. */ - lex->sql_command= SQLCOM_SHOW_FIELDS; thd->force_read_stats= get_schema_table_idx(schema_table) == SCH_STATISTICS; + lex->sql_command= SQLCOM_SHOW_FIELDS; result= (open_temporary_tables(thd, table_list) || open_normal_and_derived_tables(thd, table_list, (MYSQL_OPEN_IGNORE_FLUSH | @@ -4281,16 +4281,15 @@ fill_schema_table_by_open(THD *thd, bool is_show_fields_or_keys, (can_deadlock ? MYSQL_OPEN_FAIL_ON_MDL_CONFLICT : 0)), DT_PREPARE | DT_CREATE)); - - (void) read_statistics_for_tables_if_needed(thd, table_list); - thd->force_read_stats= false; - /* Restore old value of sql_command back as it is being looked at in process_table() function. */ lex->sql_command= old_lex->sql_command; + (void) read_statistics_for_tables_if_needed(thd, table_list); + thd->force_read_stats= false; + DEBUG_SYNC(thd, "after_open_table_ignore_flush"); /*

1 0

[Commits] de0ecf1c921: MDEV-19352: Server crash in alloc_histograms_for_table_share upon query from information schema
by Varun 30 Apr '19

30 Apr '19

revision-id: de0ecf1c9211a33071c078c90e940ff1d8419f1d (mariadb-10.1.38-156-gde0ecf1c921) parent(s): 4383265ccbbd7bb7339f3f79faf84a28a2b51120 author: Varun Gupta committer: Varun Gupta timestamp: 2019-05-01 01:44:45 +0530 message: MDEV-19352: Server crash in alloc_histograms_for_table_share upon query from information schema To read histograms for a table, we should check if the allocation of statistics was done or not, if not done we should not try to read histograms for such a table. --- mysql-test/r/stat_tables.result | 18 ++++++++++++++++++ mysql-test/r/stat_tables_innodb.result | 18 ++++++++++++++++++ mysql-test/t/stat_tables.test | 21 +++++++++++++++++++++ sql/sql_statistics.cc | 5 +++-- 4 files changed, 60 insertions(+), 2 deletions(-) diff --git a/mysql-test/r/stat_tables.result b/mysql-test/r/stat_tables.result index bd3e9ed7a40..0a53a5ae99d 100644 --- a/mysql-test/r/stat_tables.result +++ b/mysql-test/r/stat_tables.result @@ -692,5 +692,23 @@ DROP DATABASE dbt3_s001; delete from mysql.table_stats; delete from mysql.column_stats; delete from mysql.index_stats; +# +# MDEV-19352: Server crash in alloc_histograms_for_table_share upon query from information schema +# +use test; +set @save_optimizer_use_condition_selectivity= @@optimizer_use_condition_selectivity; +set @@optimizer_use_condition_selectivity= 4; +set use_stat_tables='preferably'; +CREATE TABLE t1 (a INT); +CREATE TABLE t2 (b INT); +CREATE VIEW v AS SELECT * FROM t1 JOIN t2; +INSERT INTO t2 SELECT * FROM x; +ERROR 42S02: Table 'test.x' doesn't exist +select * from information_schema.tables where table_name='v'; +TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE ENGINE VERSION ROW_FORMAT TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE AUTO_INCREMENT CREATE_TIME UPDATE_TIME CHECK_TIME TABLE_COLLATION CHECKSUM CREATE_OPTIONS TABLE_COMMENT +def test v VIEW NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL VIEW +drop table t1,t2; +drop view v; +set @@optimizer_use_condition_selectivity= @save_optimizer_use_condition_selectivity; set @save_optimizer_switch=@@optimizer_switch; set use_stat_tables=@save_use_stat_tables; diff --git a/mysql-test/r/stat_tables_innodb.result b/mysql-test/r/stat_tables_innodb.result index 579d19462e7..9a93b479664 100644 --- a/mysql-test/r/stat_tables_innodb.result +++ b/mysql-test/r/stat_tables_innodb.result @@ -719,6 +719,24 @@ DROP DATABASE dbt3_s001; delete from mysql.table_stats; delete from mysql.column_stats; delete from mysql.index_stats; +# +# MDEV-19352: Server crash in alloc_histograms_for_table_share upon query from information schema +# +use test; +set @save_optimizer_use_condition_selectivity= @@optimizer_use_condition_selectivity; +set @@optimizer_use_condition_selectivity= 4; +set use_stat_tables='preferably'; +CREATE TABLE t1 (a INT); +CREATE TABLE t2 (b INT); +CREATE VIEW v AS SELECT * FROM t1 JOIN t2; +INSERT INTO t2 SELECT * FROM x; +ERROR 42S02: Table 'test.x' doesn't exist +select * from information_schema.tables where table_name='v'; +TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE ENGINE VERSION ROW_FORMAT TABLE_ROWS AVG_ROW_LENGTH DATA_LENGTH MAX_DATA_LENGTH INDEX_LENGTH DATA_FREE AUTO_INCREMENT CREATE_TIME UPDATE_TIME CHECK_TIME TABLE_COLLATION CHECKSUM CREATE_OPTIONS TABLE_COMMENT +def test v VIEW NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL VIEW +drop table t1,t2; +drop view v; +set @@optimizer_use_condition_selectivity= @save_optimizer_use_condition_selectivity; set @save_optimizer_switch=@@optimizer_switch; set use_stat_tables=@save_use_stat_tables; set optimizer_switch=@save_optimizer_switch_for_stat_tables_test; diff --git a/mysql-test/t/stat_tables.test b/mysql-test/t/stat_tables.test index 97f9f08569f..2727f8d8bb1 100644 --- a/mysql-test/t/stat_tables.test +++ b/mysql-test/t/stat_tables.test @@ -453,6 +453,27 @@ delete from mysql.table_stats; delete from mysql.column_stats; delete from mysql.index_stats; +--echo # +--echo # MDEV-19352: Server crash in alloc_histograms_for_table_share upon query from information schema +--echo # + +use test; +set @save_optimizer_use_condition_selectivity= @@optimizer_use_condition_selectivity; +set @@optimizer_use_condition_selectivity= 4; +set use_stat_tables='preferably'; + +CREATE TABLE t1 (a INT); +CREATE TABLE t2 (b INT); +CREATE VIEW v AS SELECT * FROM t1 JOIN t2; +--error ER_NO_SUCH_TABLE +INSERT INTO t2 SELECT * FROM x; + +select * from information_schema.tables where table_name='v'; + +drop table t1,t2; +drop view v; +set @@optimizer_use_condition_selectivity= @save_optimizer_use_condition_selectivity; + set @save_optimizer_switch=@@optimizer_switch; set use_stat_tables=@save_use_stat_tables; diff --git a/sql/sql_statistics.cc b/sql/sql_statistics.cc index 061622a2cd6..8dc78e0327e 100644 --- a/sql/sql_statistics.cc +++ b/sql/sql_statistics.cc @@ -3285,12 +3285,13 @@ int read_statistics_for_tables_if_needed(THD *thd, TABLE_LIST *tables) if (table_share->stats_cb.stats_is_read) tl->table->stats_is_read= TRUE; if (thd->variables.optimizer_use_condition_selectivity > 3 && - table_share && !table_share->stats_cb.histograms_are_read) + table_share && table_share->stats_cb.stats_can_be_read && + !table_share->stats_cb.histograms_are_read) { (void) read_histograms_for_table(thd, tl->table, stat_tables); table_share->stats_cb.histograms_are_read= TRUE; } - if (table_share->stats_cb.stats_is_read) + if (table_share->stats_cb.histograms_are_read) tl->table->histograms_are_read= TRUE; } }

1 0

[Commits] b9dc777384d: removed unnided spaces
by Oleksandr Byelkin 30 Apr '19

30 Apr '19

revision-id: b9dc777384db82fd48cb56bb517b7a068d6919e2 (mariadb-10.1.38-155-gb9dc777384d) parent(s): 065948357369fa88ce1698b0720811965707e99e author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2019-04-30 11:38:27 +0200 message: removed unnided spaces --- mysql-test/t/ps.test | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mysql-test/t/ps.test b/mysql-test/t/ps.test index 60567033d8f..c8fc3e3177e 100644 --- a/mysql-test/t/ps.test +++ b/mysql-test/t/ps.test @@ -3934,13 +3934,13 @@ DELIMITER ;/ CREATE TABLE t1 (a INT); CREATE TABLE t2 (b INT); - + #EXPLAIN UPDATE t1, t2 SET a = 1; PREPARE stmt FROM 'EXPLAIN UPDATE t1, t2 SET a = 1'; EXECUTE stmt; EXECUTE stmt; deallocate prepare stmt; - + # Cleanup DROP TABLE t1, t2;

1 0

[Commits] 06594835736: MDEV-14572: Assertion `! is_set()' failed in Diagnostics_area::set_eof_status upon EXPLAIN UPDATE in PS
by Oleksandr Byelkin 30 Apr '19

30 Apr '19

revision-id: 065948357369fa88ce1698b0720811965707e99e (mariadb-10.1.38-154-g06594835736) parent(s): a8793a2c02f805a4a1c4dbd1416b594169b77541 author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2019-04-30 11:35:52 +0200 message: MDEV-14572: Assertion `! is_set()' failed in Diagnostics_area::set_eof_status upon EXPLAIN UPDATE in PS Restore EXPAIN flag in SELECT_LEX before execution multi-update by flag in LEX (the same but in other way made before INSERT/DELETE/SELECT) Without it, mysql_update() didn't know that there will be EXPLAIN result set and was sending OK at the end of the update, which conflicted with the EOF sent later by EXPLAIN. --- mysql-test/r/ps.result | 17 +++++++++++++++++ mysql-test/t/ps.test | 16 ++++++++++++++++ sql/sql_parse.cc | 10 ++++++++++ 3 files changed, 43 insertions(+) diff --git a/mysql-test/r/ps.result b/mysql-test/r/ps.result index b509a2122b0..0d305b37bd3 100644 --- a/mysql-test/r/ps.result +++ b/mysql-test/r/ps.result @@ -4397,5 +4397,22 @@ END; 1 1 # +# MDEV-14572: Assertion `! is_set()' failed in +# Diagnostics_area::set_eof_status upon EXPLAIN UPDATE in PS +# +CREATE TABLE t1 (a INT); +CREATE TABLE t2 (b INT); +PREPARE stmt FROM 'EXPLAIN UPDATE t1, t2 SET a = 1'; +EXECUTE stmt; +id select_type table type possible_keys key key_len ref rows Extra +1 SIMPLE t1 system NULL NULL NULL NULL 0 const row not found +1 SIMPLE t2 system NULL NULL NULL NULL 0 const row not found +EXECUTE stmt; +id select_type table type possible_keys key key_len ref rows Extra +1 SIMPLE t1 system NULL NULL NULL NULL 0 const row not found +1 SIMPLE t2 system NULL NULL NULL NULL 0 const row not found +deallocate prepare stmt; +DROP TABLE t1, t2; +# # End of 10.1 tests # diff --git a/mysql-test/t/ps.test b/mysql-test/t/ps.test index e1e8dfeeb17..60567033d8f 100644 --- a/mysql-test/t/ps.test +++ b/mysql-test/t/ps.test @@ -3927,6 +3927,22 @@ END; / DELIMITER ;/ +--echo # +--echo # MDEV-14572: Assertion `! is_set()' failed in +--echo # Diagnostics_area::set_eof_status upon EXPLAIN UPDATE in PS +--echo # + +CREATE TABLE t1 (a INT); +CREATE TABLE t2 (b INT); + +#EXPLAIN UPDATE t1, t2 SET a = 1; +PREPARE stmt FROM 'EXPLAIN UPDATE t1, t2 SET a = 1'; +EXECUTE stmt; +EXECUTE stmt; +deallocate prepare stmt; + +# Cleanup +DROP TABLE t1, t2; --echo # --echo # End of 10.1 tests diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index 3f9d9190d76..73b820cf87c 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -3800,6 +3800,16 @@ mysql_execute_command(THD *thd) else res= 0; + /* + We can not use mysql_explain_union() because of parameters of + mysql_select in mysql_multi_update so just set the option if needed + */ + if (thd->lex->describe) + { + select_lex->set_explain_type(FALSE); + select_lex->options|= SELECT_DESCRIBE; + } + res= mysql_multi_update_prepare(thd); #ifdef HAVE_REPLICATION

1 0