Details
Major Description
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 t1 SELECT * FROM x; |
SELECT * FROM information_schema.tables; |
|
|
# Cleanup
|
DROP VIEW v; |
DROP TABLE t1, t2; |
|
10.4 81f6a3b0 |
#3 <signal handler called>
|
#4 0x000056230487eecc in alloc_histograms_for_table_share (thd=0x7f1744000b00, table_share=0x7f174414c508, is_safe=false) at /data/src/10.4/sql/sql_statistics.cc:2446
|
#5 0x0000562304880a36 in read_histograms_for_table (thd=0x7f1744000b00, table=0x7f174414eae0, stat_tables=0x7f17540604e0) at /data/src/10.4/sql/sql_statistics.cc:3292
|
#6 0x0000562304880e8a in read_statistics_for_tables_if_needed (thd=0x7f1744000b00, tables=0x7f1744043c38) at /data/src/10.4/sql/sql_statistics.cc:3374
|
#7 0x0000562304865694 in fill_schema_table_by_open (thd=0x7f1744000b00, mem_root=0x7f1754063680, is_show_fields_or_keys=false, table=0x7f1744157e18, schema_table=0x562305e48080 <schema_tables+2048>, orig_db_name=0x7f1744133408, orig_table_name=0x7f1744133460, open_tables_state_backup=0x7f17540636d0, can_deadlock=false) at /data/src/10.4/sql/sql_show.cc:4645
|
#8 0x0000562304866fa9 in get_all_tables (thd=0x7f1744000b00, tables=0x7f1744015c60, cond=0x0) at /data/src/10.4/sql/sql_show.cc:5284
|
#9 0x000056230487803b in get_schema_tables_result (join=0x7f17440186c8, executed_place=PROCESSED_BY_JOIN_EXEC) at /data/src/10.4/sql/sql_show.cc:8878
|
#10 0x000056230480cf98 in JOIN::exec_inner (this=0x7f17440186c8) at /data/src/10.4/sql/sql_select.cc:4346
|
#11 0x000056230480c41e in JOIN::exec (this=0x7f17440186c8) at /data/src/10.4/sql/sql_select.cc:4171
|
#12 0x000056230480dad0 in mysql_select (thd=0x7f1744000b00, tables=0x7f1744015c60, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684619520, result=0x7f17440186a0, unit=0x7f1744004a28, select_lex=0x7f1744015688) at /data/src/10.4/sql/sql_select.cc:4603
|
#13 0x00005623047fe040 in handle_select (thd=0x7f1744000b00, lex=0x7f1744004960, result=0x7f17440186a0, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:424
|
#14 0x00005623047c78d9 in execute_sqlcom_select (thd=0x7f1744000b00, all_tables=0x7f1744015c60) at /data/src/10.4/sql/sql_parse.cc:6597
|
#15 0x00005623047bceaf in mysql_execute_command (thd=0x7f1744000b00) at /data/src/10.4/sql/sql_parse.cc:3886
|
#16 0x00005623047cb65f in mysql_parse (thd=0x7f1744000b00, rawbuf=0x7f17440155d8 "SELECT * FROM information_schema.tables", length=39, parser_state=0x7f1754065180, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8149
|
#17 0x00005623047b70b6 in dispatch_command (command=COM_QUERY, thd=0x7f1744000b00, packet=0x7f17441398f1 "SELECT * FROM information_schema.tables", packet_length=39, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1828
|
#18 0x00005623047b589c in do_command (thd=0x7f1744000b00) at /data/src/10.4/sql/sql_parse.cc:1361
|
#19 0x000056230492dcad in do_handle_one_connection (connect=0x562307a58530) at /data/src/10.4/sql/sql_connect.cc:1398
|
#20 0x000056230492da1e in handle_one_connection (arg=0x562307a58530) at /data/src/10.4/sql/sql_connect.cc:1301
|
#21 0x0000562304d52d9d in pfs_spawn_thread (arg=0x562307b5c060) at /data/src/10.4/storage/perfschema/pfs.cc:1862
|
#22 0x00007f175bf86494 in start_thread (arg=0x7f1754066700) at pthread_create.c:333
|
#23 0x00007f1759f4e93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
All of debug, ASAN and non-debug builds are affected.
The problem appeared in 10.4 after this merge:
commit e6bdf77e4be48750c4808a09af197ed91fd69a61
|
Merge: 1599825 acf6f92
|
Author: Marko Mäkelä
|
Date: Thu Apr 25 16:05:20 2019 +0300
|
|
|
Merge 10.3 into 10.4
|
|
In is_eits_usable(), we disable an assertion that fails due to
|
MDEV-19334.
|
Note: Even though the problem appeared after the merge above, I can't reproduce it on 10.3 even with all 10.4-specific optimizer options I can think of:
perl ./mtr bug.2230 --mysqld=--optimizer-use-condition-selectivity=4 --mysqld=--use-stat-tables=PREFERABLY --mysqld=--histogram-size=254 --mysqld=--histogram-type=DOUBLE_PREC_HB
|
|
|
...
|
bug.2230 [ pass ] 114
|
--------------------------------------------------------------------------
|
The servers were restarted 0 times
|
Spent 0.114 of 9 seconds executing testcases
|
|
|
Completed: All 1 tests were successful.
|
Attachments
Activity
A small patch needs to be applied, we need to set the correct sql_command, aligning this with higher versions, sort of a side effect of MDEV-17605
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;
|
-
|
|
For all versions the test case that fails after applying the above patch (needed for 10.1 and 10.2)
--source include/have_innodb.inc
|
set use_stat_tables='preferably';
|
set optimizer_use_condition_selectivity=4;
|
set histogram_size=255;
|
|
|
|
|
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 t1 SELECT * FROM x;
|
SELECT * FROM information_schema.tables where TABLE_NAME in ('v');
|
|
|
# Cleanup
|
DROP VIEW v;
|
DROP TABLE t1, t2
|
What we needed for in the test case was that for one table we have allocated statistics (that is table t1 in this case, with insert we allocate statistics to the TABLE_SHARE object)
For table t2 we don't allocate statistics, as no statement(no insert) that calls alloc_statistics_for_table_share()
Updated Patch as @igor requested
http://lists.askmonty.org/pipermail/commits/2019-April/013715.html
After Igor's fix for
MDEV-19351, this is reproducible on 10.3 even.This case should be reproducible on all versions starting from 10.1 . Looks like this would also solve the issue of
MDEV-19079