[MDEV-18315] Assertion `instant.fields[i].col->same_format(*fields[i] .col)' failed in dict_index_t::instant_add_field Created: 2019-01-20  Updated: 2019-01-21  Resolved: 2019-01-21

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB
Affects Version/s: 10.4
Fix Version/s: 10.4.2

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-18316 Assertion `is_added()' failed in dict... Closed

 Description   

--source include/have_innodb.inc
 
CREATE TABLE t1 (a INT, b INT) ENGINE=InnoDB;
INSERT IGNORE INTO t1 VALUES (1,1);
ALTER TABLE t1 ADD f DATE AFTER a;
ALTER TABLE t1 DROP b, DROP f;
 
# Cleanup
DROP TABLE t1;

10.4 4edb29380c9

mysqld: /data/src/10.4/storage/innobase/handler/handler0alter.cc:461: void dict_index_t::instant_add_field(const dict_index_t&): Assertion `instant.fields[i].col->same_format(*fields[i] .col)' failed.
190121  1:20:54 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fdcd296eee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x00005651a9ea7013 in dict_index_t::instant_add_field (this=0x7fdc7815aa28, instant=...) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:460
#9  0x00005651a9ea87ee in dict_table_t::instant_column (this=0x7fdc781560e8, table=..., col_map=0x7fdc7806f728) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:625
#10 0x00005651a9eaa89b in ha_innobase_inplace_ctx::instant_column (this=0x7fdc78016320) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:1080
#11 0x00005651a9e90937 in innobase_instant_try (ha_alter_info=0x7fdccc4e4bc0, ctx=0x7fdc78016320, altered_table=0x7fdc7815cca0, table=0x7fdc7818d060, trx=0x7fdccc77f258) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:5495
#12 0x00005651a9eadb73 in commit_try_norebuild (ha_alter_info=0x7fdccc4e4bc0, ctx=0x7fdc78016320, altered_table=0x7fdc7815cca0, old_table=0x7fdc7818d060, trx=0x7fdccc77f258, table_name=0x7fdc78070e5d "t1") at /data/src/10.4/storage/innobase/handler/handler0alter.cc:10160
#13 0x00005651a9e9f8e6 in ha_innobase::commit_inplace_alter_table (this=0x7fdc7818dc98, altered_table=0x7fdc7815cca0, ha_alter_info=0x7fdccc4e4bc0, commit=true) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:10793
#14 0x00005651a9b2ff82 in handler::ha_commit_inplace_alter_table (this=0x7fdc7818dc98, altered_table=0x7fdc7815cca0, ha_alter_info=0x7fdccc4e4bc0, commit=true) at /data/src/10.4/sql/handler.cc:4492
#15 0x00005651a98ef570 in mysql_inplace_alter_table (thd=0x7fdc78000b00, table_list=0x7fdc780150a0, table=0x7fdc7818d060, altered_table=0x7fdc7815cca0, ha_alter_info=0x7fdccc4e4bc0, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7fdccc4e4cf0, alter_ctx=0x7fdccc4e58e0) at /data/src/10.4/sql/sql_table.cc:7590
#16 0x00005651a98f53d1 in mysql_alter_table (thd=0x7fdc78000b00, new_db=0x7fdc780051e0, new_name=0x7fdc780055b0, create_info=0x7fdccc4e64d0, table_list=0x7fdc780150a0, alter_info=0x7fdccc4e6410, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:9690
#17 0x00005651a997fa4f in Sql_cmd_alter_table::execute (this=0x7fdc78015730, thd=0x7fdc78000b00) at /data/src/10.4/sql/sql_alter.cc:497
#18 0x00005651a981cceb in mysql_execute_command (thd=0x7fdc78000b00) at /data/src/10.4/sql/sql_parse.cc:6314
#19 0x00005651a9821c16 in mysql_parse (thd=0x7fdc78000b00, rawbuf=0x7fdc78014fb8 "ALTER TABLE t1 DROP b, DROP f", length=29, parser_state=0x7fdccc4e7600, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8116
#20 0x00005651a980edb3 in dispatch_command (command=COM_QUERY, thd=0x7fdc78000b00, packet=0x7fdc7800b441 "ALTER TABLE t1 DROP b, DROP f", packet_length=29, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1852
#21 0x00005651a980d7d7 in do_command (thd=0x7fdc78000b00) at /data/src/10.4/sql/sql_parse.cc:1397
#22 0x00005651a9979a92 in do_handle_one_connection (connect=0x5651ad1bdcf0) at /data/src/10.4/sql/sql_connect.cc:1402
#23 0x00005651a9979816 in handle_one_connection (arg=0x5651ad1bdcf0) at /data/src/10.4/sql/sql_connect.cc:1308
#24 0x00005651a9e38dec in pfs_spawn_thread (arg=0x5651ad1b8c70) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#25 0x00007fdcd4645494 in start_thread (arg=0x7fdccc4e8700) at pthread_create.c:333
#26 0x00007fdcd2a2b93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Not reproducible on 10.3.



 Comments   
Comment by Marko Mäkelä [ 2019-01-21 ]

The problem is here in dict_table_t::prepare_instant():

			/* This column is being dropped. */
			DBUG_ASSERT(d < n_drop);
			f.col = &instant->dropped[d++];

We are wrongly assuming that the instantly dropped columns appear in dict_instant_t::dropped in the same order in which they appeared in the index. In this case, because of the preceding ADD f DATE AFTER a, the order of the columns will be a,f,b in the table, but a,b,f in the index. The mismatch is being caught, because the column length is 3 bytes for DATE but 4 bytes for INT.

Generated at Thu Feb 08 08:43:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.