[MDEV-21478] Assertion `col->len == sizeof(doc_id_t)' failed in dict_load_columns or warning InnoDB: Table test/t1 contains 1 user defined columns in InnoDB, but 2 columns in MariaDB - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL)
Fix Version/s: 10.2.37, 10.3.28, 10.4.18, 10.5.9, 10.6.0
Component/s: Full-text Search, Storage Engine - InnoDB
Labels:
None

Description

--source include/have_innodb.inc

CREATE  TABLE t1 (a INT) ENGINE=InnoDB;

ALTER TABLE t1 ADD fts_doc_id INT;

--source include/restart_mysqld.inc

CHECK TABLE t1;

# Cleanup

DROP TABLE t1;

10.4 debug 2d4b6571
mysqld: /data/src/10.4/storage/innobase/dict/dict0load.cc:1856: void dict_load_columns(dict_table_t, mem_heap_t): Assertion `col->len == sizeof(doc_id_t)' failed.
200114 23:20:52 [ERROR] mysqld got signal 6 ;

#7 0x00007f6d06ab2f12 in __GI___assert_fail (assertion=0x55d628aa7f6f "col->len == sizeof(doc_id_t)", file=0x55d628aa7188 "/data/src/10.4/storage/innobase/dict/dict0load.cc", line=1856, function=0x55d628aaa4a0 <dict_load_columns(dict_table_t, mem_block_info_t)::__PRETTY_FUNCTION__> "void dict_load_columns(dict_table_t, mem_heap_t)") at assert.c:101
#8 0x000055d6283af159 in dict_load_columns (table=0x7f6cb402baa8, heap=0x7f6cb4037a80) at /data/src/10.4/storage/innobase/dict/dict0load.cc:1856
#9 0x000055d6283b2f3c in dict_load_table_one (name=..., ignore_err=DICT_ERR_IGNORE_FK_NOKEY, fk_tables=std::deque with 0 elements) at /data/src/10.4/storage/innobase/dict/dict0load.cc:2940
#10 0x000055d6283b20d0 in dict_load_table (name=0x7f6d000812e0 "test/t1", ignore_err=DICT_ERR_IGNORE_FK_NOKEY) at /data/src/10.4/storage/innobase/dict/dict0load.cc:2748
#11 0x000055d628391f85 in dict_table_open_on_name (table_name=0x7f6d000812e0 "test/t1", dict_locked=0, try_drop=1, ignore_err=DICT_ERR_IGNORE_FK_NOKEY) at /data/src/10.4/storage/innobase/dict/dict0dict.cc:886
#12 0x000055d62802fd7c in ha_innobase::open_dict_table (norm_name=0x7f6d000812e0 "test/t1", is_partition=false, ignore_err=DICT_ERR_IGNORE_FK_NOKEY) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:6378
#13 0x000055d62802ed4a in ha_innobase::open (this=0x7f6cb402af68, name=0x7f6cb4027be0 "./test/t1") at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:6091
#14 0x000055d627debaa3 in handler::ha_open (this=0x7f6cb402af68, table_arg=0x7f6cb4029ca0, name=0x7f6cb4027be0 "./test/t1", mode=2, test_if_locked=50, mem_root=0x0, partitions_to_open=0x0) at /data/src/10.4/sql/handler.cc:2747
#15 0x000055d627bb537b in open_table_from_share (thd=0x7f6cb4000af0, share=0x7f6cb4027658, alias=0x7f6cb4015578, db_stat=33, prgflag=8, ha_open_flags=50, outparam=0x7f6cb4029ca0, is_create_table=false, partitions_to_open=0x0) at /data/src/10.4/sql/table.cc:3951
#16 0x000055d6279e2431 in open_table (thd=0x7f6cb4000af0, table_list=0x7f6cb4015530, ot_ctx=0x7f6d00081b10) at /data/src/10.4/sql/sql_base.cc:2086
#17 0x000055d6279e5edd in open_and_process_table (thd=0x7f6cb4000af0, tables=0x7f6cb4015530, counter=0x7f6d00081ba4, flags=0, prelocking_strategy=0x7f6d00081c28, has_prelocking_list=false, ot_ctx=0x7f6d00081b10) at /data/src/10.4/sql/sql_base.cc:3850
#18 0x000055d6279e7177 in open_tables (thd=0x7f6cb4000af0, options=..., start=0x7f6d00081b88, counter=0x7f6d00081ba4, flags=0, prelocking_strategy=0x7f6d00081c28) at /data/src/10.4/sql/sql_base.cc:4324
#19 0x000055d6279e92f4 in open_and_lock_tables (thd=0x7f6cb4000af0, options=..., tables=0x7f6cb4015530, derived=true, flags=0, prelocking_strategy=0x7f6d00081c28) at /data/src/10.4/sql/sql_base.cc:5217
#20 0x000055d6279a3029 in open_and_lock_tables (thd=0x7f6cb4000af0, tables=0x7f6cb4015530, derived=true, flags=0) at /data/src/10.4/sql/sql_base.h:505
#21 0x000055d627c1cbe0 in open_only_one_table (thd=0x7f6cb4000af0, table=0x7f6cb4015530, repair_table_use_frm=false, is_view_operator_func=true) at /data/src/10.4/sql/sql_admin.cc:395
#22 0x000055d627c1d1d1 in mysql_admin_table(THD , TABLE_LIST , HA_CHECK_OPT , const char , thr_lock_type, bool, bool, uint, int ()(THD , TABLE_LIST , HA_CHECK_OPT ), struct {...}, int ()(THD , TABLE_LIST , HA_CHECK_OPT )) (thd=0x7f6cb4000af0, tables=0x7f6cb4015530, check_opt=0x7f6cb4005cc8, operator_name=0x55d6287cc3b1 "check", lock_type=TL_READ_NO_INSERT, org_open_for_modify=false, repair_table_use_frm=false, extra_open_options=32, prepare_func=0x0, operator_func=(int (handler::)(handler const, THD , HA_CHECK_OPT )) 0x55d627df0cf0 <handler::ha_check(THD, st_ha_check_opt)>, view_operator_func=0x55d627ba5de8 <view_check(THD, TABLE_LIST, st_ha_check_opt*)>) at /data/src/10.4/sql/sql_admin.cc:520
#23 0x000055d627c203fe in Sql_cmd_check_table::execute (this=0x7f6cb4015bf8, thd=0x7f6cb4000af0) at /data/src/10.4/sql/sql_admin.cc:1352
#24 0x000055d627a90d95 in mysql_execute_command (thd=0x7f6cb4000af0) at /data/src/10.4/sql/sql_parse.cc:6102
#25 0x000055d627a96457 in mysql_parse (thd=0x7f6cb4000af0, rawbuf=0x7f6cb4015478 "CHECK TABLE t1", length=14, parser_state=0x7f6d00083160, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7901
#26 0x000055d627a815fc in dispatch_command (command=COM_QUERY, thd=0x7f6cb4000af0, packet=0x7f6cb40083a1 "", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
#27 0x000055d627a7fc89 in do_command (thd=0x7f6cb4000af0) at /data/src/10.4/sql/sql_parse.cc:1360
#28 0x000055d627c08c51 in do_handle_one_connection (connect=0x55d62ac139e0) at /data/src/10.4/sql/sql_connect.cc:1412
#29 0x000055d627c089a0 in handle_one_connection (arg=0x55d62ac139e0) at /data/src/10.4/sql/sql_connect.cc:1316
#30 0x000055d62860eb0d in pfs_spawn_thread (arg=0x55d62ab80150) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#31 0x00007f6d08a3b4a4 in start_thread (arg=0x7f6d00084700) at pthread_create.c:456
#32 0x00007f6d06b6fd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

10.4 non-debug 2d4b6571

2020-01-14 23:21:44 8 [Warning] InnoDB: Table test/t1 contains 1 user defined columns in InnoDB, but 2 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue.

Reproducible with 10.1-10.5.

Attachments

Activity

Ascending order - Click to sort in descending order

Thirunarayanan Balathandayuthapani added a comment - 2020-12-15 10:59

Patch is in bb-10.2-~~MDEV-21478~~

Thirunarayanan Balathandayuthapani added a comment - 2020-12-15 10:59 Patch is in bb-10.2- MDEV-21478

Marko Mäkelä added a comment - 2020-12-17 16:46

The proposed fix would start to treat FTS_DOC_ID (case-insensitively) as a reserved column name in InnoDB native ALTER TABLE…ADD COLUMN, but not in CREATE TABLE or TRUNCATE TABLE or elsewhere.

I would expect the bug to repeat also with the following:

--source include/have_innodb.inc

CREATE TABLE t1 (a INT, fts_doc_id INT) ENGINE=InnoDB;

--source include/restart_mysqld.inc

CHECK TABLE t1;

DROP TABLE t1;

I think that we must consider the history here. Before MySQL 5.6 (and MariaDB 10.0) introduced fulltext search into InnoDB, the column name FTS_DOC_ID and the index name FTS_DOC_ID_INDEX were not special in any way. Even starting with those versions, those names are special only if:

the table contains at least one FULLTEXT INDEX
FTS_DOC_ID is written in all caps
the column type is BIGINT UNSIGNED NOT NULL
there is a UNIQUE index FTS_DOC_ID_INDEX in all caps defined on the column

Note: FTS_DOC_ID_INDEX may or may not be explicitly created by the user in SQL. InnoDB will create a hidden index by that name if needed, either on a user-specified FTS_DOC_ID column or an automatically created hidden FTS_DOC_ID column.

I think that instead of changing the column name to be more reserved, we must improve the consistency checks according to the above description.

Marko Mäkelä added a comment - 2020-12-17 16:46 The proposed fix would start to treat FTS_DOC_ID (case-insensitively) as a reserved column name in InnoDB native ALTER TABLE…ADD COLUMN , but not in CREATE TABLE or TRUNCATE TABLE or elsewhere. I would expect the bug to repeat also with the following: --source include/have_innodb.inc CREATE TABLE t1 (a INT , fts_doc_id INT ) ENGINE=InnoDB; --source include/restart_mysqld.inc CHECK TABLE t1; DROP TABLE t1; I think that we must consider the history here. Before MySQL 5.6 (and MariaDB 10.0) introduced fulltext search into InnoDB, the column name FTS_DOC_ID and the index name FTS_DOC_ID_INDEX were not special in any way. Even starting with those versions, those names are special only if: the table contains at least one FULLTEXT INDEX FTS_DOC_ID is written in all caps the column type is BIGINT UNSIGNED NOT NULL there is a UNIQUE index FTS_DOC_ID_INDEX in all caps defined on the column Note: FTS_DOC_ID_INDEX may or may not be explicitly created by the user in SQL. InnoDB will create a hidden index by that name if needed, either on a user-specified FTS_DOC_ID column or an automatically created hidden FTS_DOC_ID column. I think that instead of changing the column name to be more reserved, we must improve the consistency checks according to the above description.

Thirunarayanan Balathandayuthapani added a comment - 2020-12-29 02:48

Currently, create table with fts_doc_id fails in 10.2+

 'CREATE TABLE t1 (a INT, fts_doc_id INT) ENGINE=InnoDB' failed: 1166: Incorrect column name 'fts_doc_id'

Thirunarayanan Balathandayuthapani added a comment - 2020-12-29 02:48 Currently, create table with fts_doc_id fails in 10.2+ 'CREATE TABLE t1 (a INT, fts_doc_id INT) ENGINE=InnoDB' failed: 1166: Incorrect column name 'fts_doc_id'

Marko Mäkelä added a comment - 2021-01-04 07:47

thiru, thank you. I stand corrected that already starting with this commit in MySQL 5.6.4 (well before the 5.6.10 GA release), whenever a case-insensitive match of the column name FTS_DOC_ID is found, it must be written in all caps, or otherwise an error will be reported. Because that handling has been present in MariaDB GA releases since the 10.0 release, we’d better retain the logic in existing GA versions.

It seems that to fix the reported problem, the call of create_table_check_doc_id_col() is misplaced and it should be either moved to another member function of create_table_info_t or the logic should be duplicated in prepare_inplace_alter_table_dict(). The fix has to be tested on both 10.2 and 10.3, with both ALGORITHM=COPY and ALGORITHM=INSTANT. In 10.3, it has to be tested with all relevant values of the parameter innodb_instant_alter_column_allowed, which was introduced in ~~MDEV-20590~~.

Marko Mäkelä added a comment - 2021-01-04 07:47 thiru , thank you. I stand corrected that already starting with this commit in MySQL 5.6.4 (well before the 5.6.10 GA release), whenever a case-insensitive match of the column name FTS_DOC_ID is found, it must be written in all caps, or otherwise an error will be reported. Because that handling has been present in MariaDB GA releases since the 10.0 release, we’d better retain the logic in existing GA versions. It seems that to fix the reported problem, the call of create_table_check_doc_id_col() is misplaced and it should be either moved to another member function of create_table_info_t or the logic should be duplicated in prepare_inplace_alter_table_dict() . The fix has to be tested on both 10.2 and 10.3, with both ALGORITHM=COPY and ALGORITHM=INSTANT . In 10.3, it has to be tested with all relevant values of the parameter innodb_instant_alter_column_allowed , which was introduced in MDEV-20590 .

MariaDB Server

Assertion `col->len == sizeof(doc_id_t)' failed in dict_load_columns or warning InnoDB: Table test/t1 contains 1 user defined columns in InnoDB, but 2 columns in MariaDB

Details

Description

Attachments

Activity

People

Dates

Git Integration