Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11
Description
I am setting it to Minor due to the unrealistic value of histogram_size. However, I can't tell for sure whether the failure is specific to the meaningless histogram_size or just the combination of histogram_size and data volume/values. I expect the development analysis will clarify it.
CREATE TABLE t1 (a INT); |
INSERT INTO t1 VALUES (1),(2),(3),(4),(5),(6),(7),(8); |
INSERT INTO t1 SELECT * FROM t1; |
ALTER TABLE t1 ADD SYSTEM VERSIONING; |
INSERT INTO t1 VALUES (1),(2),(3),(4); |
SET HISTOGRAM_SIZE= 5; |
ANALYZE TABLE t1 PERSISTENT FOR ALL; |
SELECT * from t1 WHERE row_start IN (SELECT row_end FROM t1); |
|
# Cleanup
|
DROP TABLE t1; |
10.4 debug 5d471453 |
mysqld: /data/src/10.4/sql/sql_statistics.h:177: uint Histogram::get_value(uint): Assertion `i < get_width()' failed.
|
200712 15:19:19 [ERROR] mysqld got signal 6 ;
|
|
#7 0x00007f954b92bf12 in __GI___assert_fail (assertion=0x563fefef8385 "i < get_width()", file=0x563fefef8398 "/data/src/10.4/sql/sql_statistics.h", line=177, function=0x563fefef8d00 <Histogram::get_value(unsigned int)::__PRETTY_FUNCTION__> "uint Histogram::get_value(uint)") at assert.c:101
|
#8 0x0000563fef2af103 in Histogram::get_value (this=0x7f94e4057c90, i=2) at /data/src/10.4/sql/sql_statistics.h:177
|
#9 0x0000563fef2af238 in Histogram::find_bucket (this=0x7f94e4057c90, pos=1, first=true) at /data/src/10.4/sql/sql_statistics.h:201
|
#10 0x0000563fef2ae3e3 in Histogram::point_selectivity (this=0x7f94e4057c90, pos=1, avg_sel=0.5) at /data/src/10.4/sql/sql_statistics.cc:3874
|
#11 0x0000563fef2ae181 in get_column_range_cardinality (field=0x7f94e4077430, min_endp=0x7f95481783c0, max_endp=0x7f95481783e0, range_flag=48) at /data/src/10.4/sql/sql_statistics.cc:3783
|
#12 0x0000563fef6b9ead in records_in_column_ranges (param=0x7f9548178c00, idx=0, tree=0x7f94e405c570) at /data/src/10.4/sql/opt_range.cc:3234
|
#13 0x0000563fef6baaf7 in calculate_cond_selectivity_for_table (thd=0x7f94e4000af0, table=0x7f94e413e6f0, cond=0x7f94e40162c0) at /data/src/10.4/sql/opt_range.cc:3498
|
#14 0x0000563fef237c7f in make_join_statistics (join=0x7f94e4015eb8, tables_list=..., keyuse_array=0x7f94e40161a8) at /data/src/10.4/sql/sql_select.cc:5476
|
#15 0x0000563fef22c1f2 in JOIN::optimize_inner (this=0x7f94e4015eb8) at /data/src/10.4/sql/sql_select.cc:2263
|
#16 0x0000563fef229b32 in JOIN::optimize (this=0x7f94e4015eb8) at /data/src/10.4/sql/sql_select.cc:1610
|
#17 0x0000563fef234fda in mysql_select (thd=0x7f94e4000af0, tables=0x7f94e4013628, wild_num=1, fields=..., conds=0x7f94e40152c8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f94e4015e90, unit=0x7f94e4004a18, select_lex=0x7f94e4013068) at /data/src/10.4/sql/sql_select.cc:4673
|
#18 0x0000563fef224b46 in handle_select (thd=0x7f94e4000af0, lex=0x7f94e4004958, result=0x7f94e4015e90, setup_tables_done_option=0) at /data/src/10.4/sql/sql_select.cc:422
|
#19 0x0000563fef1eb628 in execute_sqlcom_select (thd=0x7f94e4000af0, all_tables=0x7f94e4013628) at /data/src/10.4/sql/sql_parse.cc:6358
|
#20 0x0000563fef1e1c5f in mysql_execute_command (thd=0x7f94e4000af0) at /data/src/10.4/sql/sql_parse.cc:3890
|
#21 0x0000563fef1ef5d5 in mysql_parse (thd=0x7f94e4000af0, rawbuf=0x7f94e4012f88 "SELECT * from t1 WHERE row_start IN (SELECT row_end FROM t1)", length=60, parser_state=0x7f954817a5c0, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7899
|
#22 0x0000563fef1dbb0a in dispatch_command (command=COM_QUERY, thd=0x7f94e4000af0, packet=0x7f94e414e0d1 "SELECT * from t1 WHERE row_start IN (SELECT row_end FROM t1)", packet_length=60, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1834
|
#23 0x0000563fef1da2ac in do_command (thd=0x7f94e4000af0) at /data/src/10.4/sql/sql_parse.cc:1352
|
#24 0x0000563fef363188 in do_handle_one_connection (connect=0x563ff2e99a80) at /data/src/10.4/sql/sql_connect.cc:1412
|
#25 0x0000563fef362ed7 in handle_one_connection (arg=0x563ff2e99a80) at /data/src/10.4/sql/sql_connect.cc:1316
|
#26 0x00007f954d8b44a4 in start_thread (arg=0x7f954817b700) at pthread_create.c:456
|
#27 0x00007f954b9e8d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
Reproducible on 10.4-10.5, with at least MyISAM and InnoDB.
Couldn't reproduce on 10.3, even after adding USE_STAT_TABLES=PREFERABLY, OPTIMIZER_USE_CONDITION_SELECTIVITY=4, HISTOGRAM_TYPE=DOUBLE_PREC_HB. Maybe I missed some important options.
Couldn't reproduce without versioning, with explicit timestamp columns.
No obvious problem on a non-debug build.