[MDEV-25101] Assertion `!strcmp(field->name, "table_name")' failed in btr_node_ptr_max_size after adding index on InnoDB stats table - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Minor
Resolution: Fixed
Affects Version/s: 10.2.17, 10.3.9, 10.4.2, 10.5.0, 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
Fix Version/s: 10.2.38, 10.3.29, 10.4.19, 10.5.10
Component/s: Storage Engine - InnoDB
Labels:
None

Description

--source include/have_innodb.inc

SET @stats= @@innodb_stats_persistent;

SET GLOBAL innodb_stats_persistent= ON;

ALTER TABLE mysql.innodb_index_stats ADD KEY (stat_name);

CREATE TABLE t (a INT) ENGINE=InnoDB;

# Cleanup

DROP TABLE t;

SET GLOBAL innodb_stats_persistent= @stats;

10.2 dc666780
mysqld: /data/src/10.2/storage/innobase/btr/btr0cur.cc:840: ulint btr_node_ptr_max_size(const dict_index_t*): Assertion `!strcmp(field->name, "table_name")' failed.
210310 2:46:21 [ERROR] mysqld got signal 6 ;

#7 0x00007f344ece5f36 in __GI___assert_fail (assertion=0x5610f435b990 "!strcmp(field->name, \"table_name\")", file=0x5610f435b310 "/data/src/10.2/storage/innobase/btr/btr0cur.cc", line=840, function=0x5610f435b838 "ulint btr_node_ptr_max_size(const dict_index_t*)") at assert.c:101
#8 0x00005610f3dbf621 in btr_node_ptr_max_size (index=0x7f33f4191800) at /data/src/10.2/storage/innobase/btr/btr0cur.cc:840
#9 0x00005610f3dc0320 in btr_cur_search_to_nth_level_func (index=0x7f33f4191800, level=0, tuple=0x7f33f40a2148, mode=PAGE_CUR_LE, latch_mode=2, cursor=0x7f3449147840, has_search_latch=0, file=0x5610f42f6480 "/data/src/10.2/storage/innobase/row/row0ins.cc", line=2923, mtr=0x7f3449148290, autoinc=0) at /data/src/10.2/storage/innobase/btr/btr0cur.cc:1199
#10 0x00005610f3cab907 in row_ins_sec_index_entry_low (flags=0, mode=2, index=0x7f33f4191800, offsets_heap=0x7f33f40ab540, heap=0x7f33f40ab9d0, entry=0x7f33f40a2148, trx_id=0, thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/row/row0ins.cc:2920
#11 0x00005610f3cac5ea in row_ins_sec_index_entry (index=0x7f33f4191800, entry=0x7f33f40a2148, thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/row/row0ins.cc:3215
#12 0x00005610f3cac74a in row_ins_index_entry (index=0x7f33f4191800, entry=0x7f33f40a2148, thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/row/row0ins.cc:3262
#13 0x00005610f3cacc60 in row_ins_index_entry_step (node=0x7f33f40a63e8, thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/row/row0ins.cc:3411
#14 0x00005610f3cad03b in row_ins (node=0x7f33f40a63e8, thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/row/row0ins.cc:3548
#15 0x00005610f3cad3e6 in row_ins_step (thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/row/row0ins.cc:3668
#16 0x00005610f3c7b4dc in que_thr_step (thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/que/que0que.cc:1021
#17 0x00005610f3c7b7d9 in que_run_threads_low (thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/que/que0que.cc:1103
#18 0x00005610f3c7b9a3 in que_run_threads (thr=0x7f33f40a66c0) at /data/src/10.2/storage/innobase/que/que0que.cc:1143
#19 0x00005610f3c7bc4b in que_eval_sql (info=0x7f33f41910e0, sql=0x5610f4394638 "PROCEDURE INDEX_STATS_SAVE () IS\nBEGIN\nDELETE FROM \"mysql/innodb_index_stats\"\nWHERE\ndatabase_name = :database_name AND\ntable_name = :table_name AND\nindex_name = :index_name AND\nstat_name = :stat_name;"..., reserve_dict_mutex=0, trx=0x7f3449d20228) at /data/src/10.2/storage/innobase/que/que0que.cc:1220
#20 0x00005610f3e63e9b in dict_stats_exec_sql (pinfo=0x7f33f41910e0, sql=0x5610f4394638 "PROCEDURE INDEX_STATS_SAVE () IS\nBEGIN\nDELETE FROM \"mysql/innodb_index_stats\"\nWHERE\ndatabase_name = :database_name AND\ntable_name = :table_name AND\nindex_name = :index_name AND\nstat_name = :stat_name;"..., trx=0x7f3449d20228) at /data/src/10.2/storage/innobase/dict/dict0stats.cc:306
#21 0x00005610f3e687d9 in dict_stats_save_index_stat (index=0x7f33f40aa560, last_update=1615337181, stat_name=0x7f3449148ec0 "n_diff_pfx01", stat_value=0, sample_size=0x7f33f40aa858, stat_description=0x7f3449149070 "DB_ROW_ID", trx=0x7f3449d20228) at /data/src/10.2/storage/innobase/dict/dict0stats.cc:2382
#22 0x00005610f3e692fa in dict_stats_save (table_orig=0x7f33f41734a0, only_for_index=0x0) at /data/src/10.2/storage/innobase/dict/dict0stats.cc:2602
#23 0x00005610f3e6ad32 in dict_stats_update (table=0x7f33f41734a0, stats_upd_option=DICT_STATS_EMPTY_TABLE) at /data/src/10.2/storage/innobase/dict/dict0stats.cc:3284
#24 0x00005610f3b94854 in create_table_info_t::create_table_update_dict (this=0x7f3449149730) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:12989
#25 0x00005610f3baad69 in ha_innobase::create (this=0x7f33f4036ea8, name=0x7f344914c4f0 "./test/t", form=0x7f3449149ca0, create_info=0x7f344914c920, file_per_table=true, trx=0x7f3449d20228) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:13148
#26 0x00005610f3b94b85 in ha_innobase::create (this=0x7f33f4036ea8, name=0x7f344914c4f0 "./test/t", form=0x7f3449149ca0, create_info=0x7f344914c920) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:13169
#27 0x00005610f3988f88 in handler::ha_create (this=0x7f33f4036ea8, name=0x7f344914c4f0 "./test/t", form=0x7f3449149ca0, info_arg=0x7f344914c920) at /data/src/10.2/sql/handler.cc:4515
#28 0x00005610f3989f18 in ha_create_table (thd=0x7f33f4000d90, path=0x7f344914c4f0 "./test/t", db=0x7f33f4012e18 "test", table_name=0x7f33f40127b0 "t", create_info=0x7f344914c920, frm=0x7f344914c4e0) at /data/src/10.2/sql/handler.cc:4888
#29 0x00005610f38201bf in rea_create_table (thd=0x7f33f4000d90, frm=0x7f344914c4e0, path=0x7f344914c4f0 "./test/t", db=0x7f33f4012e18 "test", table_name=0x7f33f40127b0 "t", create_info=0x7f344914c920, file=0x7f33f40131c0, no_ha_create_table=false) at /data/src/10.2/sql/unireg.cc:429
#30 0x00005610f37ca352 in create_table_impl (thd=0x7f33f4000d90, orig_db=0x7f33f4012e18 "test", orig_table_name=0x7f33f40127b0 "t", db=0x7f33f4012e18 "test", table_name=0x7f33f40127b0 "t", path=0x7f344914c4f0 "./test/t", options=..., create_info=0x7f344914c920, alter_info=0x7f344914c870, create_table_mode=0, is_trans=0x7f344914c74e, key_info=0x7f344914c4d0, key_count=0x7f344914c4c4, frm=0x7f344914c4e0) at /data/src/10.2/sql/sql_table.cc:4960
#31 0x00005610f37ca951 in mysql_create_table_no_lock (thd=0x7f33f4000d90, db=0x7f33f4012e18 "test", table_name=0x7f33f40127b0 "t", create_info=0x7f344914c920, alter_info=0x7f344914c870, is_trans=0x7f344914c74e, create_table_mode=0) at /data/src/10.2/sql/sql_table.cc:5070
#32 0x00005610f37cabdf in mysql_create_table (thd=0x7f33f4000d90, create_table=0x7f33f4012800, create_info=0x7f344914c920, alter_info=0x7f344914c870) at /data/src/10.2/sql/sql_table.cc:5138
#33 0x00005610f37db071 in Sql_cmd_create_table::execute (this=0x7f33f40127e0, thd=0x7f33f4000d90) at /data/src/10.2/sql/sql_table.cc:10984
#34 0x00005610f37035b5 in mysql_execute_command (thd=0x7f33f4000d90) at /data/src/10.2/sql/sql_parse.cc:6021
#35 0x00005610f3708407 in mysql_parse (thd=0x7f33f4000d90, rawbuf=0x7f33f40126f8 "CREATE TABLE t (a INT) ENGINE=InnoDB", length=36, parser_state=0x7f344914d5f0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7790
#36 0x00005610f36f6644 in dispatch_command (command=COM_QUERY, thd=0x7f33f4000d90, packet=0x7f33f4008b51 "CREATE TABLE t (a INT) ENGINE=InnoDB", packet_length=36, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1827
#37 0x00005610f36f513f in do_command (thd=0x7f33f4000d90) at /data/src/10.2/sql/sql_parse.cc:1381
#38 0x00005610f384fbea in do_handle_one_connection (connect=0x5610f76a3810) at /data/src/10.2/sql/sql_connect.cc:1336
#39 0x00005610f384f94f in handle_one_connection (arg=0x5610f76a3810) at /data/src/10.2/sql/sql_connect.cc:1241
#40 0x00005610f4078af0 in pfs_spawn_thread (arg=0x5610f7686c00) at /data/src/10.2/storage/perfschema/pfs.cc:1869
#41 0x00007f344f1f7609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#42 0x00007f344edd1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Reproducible on 10.2-10.6.
No obvious immediate problem on a non-debug build.

Attachments

Issue Links

is caused by

MDEV-14637 Latching order violation during btr_cur_pessimistic_delete()

Closed

Activity

Marko Mäkelä added a comment - 2021-03-10 06:10

The assertion was introduced in ~~MDEV-14637~~. I think that this is a borderline case. Why should we allow users to modify system tables?

The assertion failure here seems to be almost harmless. We would be over-estimating the maximum length of the column:

		} else if (field_max_size == NAME_LEN && i == 1

			   && (!strcmp(index->table->name.m_name,

				       TABLE_STATS_NAME)

			       || !strcmp(index->table->name.m_name,

					  INDEX_STATS_NAME))) {

			ut_ad(!strcmp(field->name, "table_name"));

			/* Interpret "table_name" as VARCHAR(199) even

			if it was incorrectly defined as VARCHAR(64).

			While the caller of ha_innobase enforces the

			maximum length on any data written, the InnoDB

			internal SQL parser will happily write as much

			data as is provided. The purpose of this hack

			is to avoid InnoDB hangs after persistent

			statistics on partitioned tables are

			deleted. */

			field_max_size = 199 * SYSTEM_CHARSET_MBMAXLEN;

In the test case, the table name is mysql.innodb_index_stats or mysql.innodb_table_stats, and the claimed length of the second index field is 64*3 bytes, but the index field name is not table_name.

I think that we could simply remove the debug assertion. This could lead to more pessimistic locking of the statistics tables, but I cannot see any ill effects.

Side note: The consistency check for the statistics tables in dict_table_schema_check() does not consider indexes at all, only the number and the names of columns.

Marko Mäkelä added a comment - 2021-03-10 06:10 The assertion was introduced in MDEV-14637 . I think that this is a borderline case. Why should we allow users to modify system tables? The assertion failure here seems to be almost harmless. We would be over-estimating the maximum length of the column: } else if (field_max_size == NAME_LEN && i == 1 && (! strcmp (index->table->name.m_name, TABLE_STATS_NAME) || ! strcmp (index->table->name.m_name, INDEX_STATS_NAME))) { ut_ad(! strcmp (field->name, "table_name" )); /* Interpret "table_name" as VARCHAR(199) even if it was incorrectly defined as VARCHAR(64). While the caller of ha_innobase enforces the maximum length on any data written, the InnoDB internal SQL parser will happily write as much data as is provided. The purpose of this hack is to avoid InnoDB hangs after persistent statistics on partitioned tables are deleted. */ field_max_size = 199 * SYSTEM_CHARSET_MBMAXLEN; } In the test case, the table name is mysql.innodb_index_stats or mysql.innodb_table_stats , and the claimed length of the second index field is 64*3 bytes, but the index field name is not table_name . I think that we could simply remove the debug assertion. This could lead to more pessimistic locking of the statistics tables, but I cannot see any ill effects. Side note: The consistency check for the statistics tables in dict_table_schema_check() does not consider indexes at all, only the number and the names of columns.

MariaDB Server

Assertion `!strcmp(field->name, "table_name")' failed in btr_node_ptr_max_size after adding index on InnoDB stats table

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration