[MDEV-17831] Assertion `supports_instant()' failed in dict_table_t::prepare_instant upon ADD COLUMN on table with KEY_BLOCK_SIZE Created: 2018-11-25  Updated: 2020-07-27  Resolved: 2018-11-26

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3.10, 10.4.0, 10.2.19
Fix Version/s: 10.4.1, 10.2.20, 10.3.12

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

Issue Links:
Relates
relates to MDEV-11369 Instant add column for InnoDB Closed
relates to MDEV-13564 TRUNCATE TABLE and undo tablespace tr... Closed
relates to MDEV-15562 Instant DROP COLUMN or changing the o... Closed
relates to MDEV-23295 Assertion `fields[i].same(instant.fie... Closed

 Description    

--source include/have_innodb.inc
 
 
 
CREATE TABLE t1 (a INT) ENGINE=InnoDB KEY_BLOCK_SIZE=4;
 
TRUNCATE t1;
 
ALTER TABLE t1 ADD COLUMN b INT;
 
 
 
# Cleanup
 
DROP TABLE t1;

10.4 27f3329ff6

 
mysqld: /data/src/10.4/storage/innobase/handler/handler0alter.cc:177: void dict_table_t::prepare_instant(const dict_table_t&, const ulint*, unsigned int&): Assertion `supports_instant()' failed.
 
181126  0:34:25 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f6b79a2bee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x000055f9e98cfe45 in dict_table_t::prepare_instant (this=0x7f6b1c133028, old=..., col_map=0x7f6b1c134400, first_alter_pos=@0x7f6b1c016478: 0) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:177
 
#9  0x000055f9e98d51b1 in ha_innobase_inplace_ctx::prepare_instant (this=0x7f6b1c016308) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:969
 
#10 0x000055f9e98c06a1 in prepare_inplace_alter_table_dict (ha_alter_info=0x7f6b6ed50bb0, altered_table=0x7f6b1c134f10, old_table=0x7f6b1c095f20, table_name=0x7f6b1c094b6d "t1", flags=39, flags2=80, fts_doc_id_col=18446744073709551615, add_fts_doc_id=false, add_fts_doc_id_idx=false) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:6385
 
#11 0x000055f9e98c559e in ha_innobase::prepare_inplace_alter_table (this=0x7f6b1c096b58, altered_table=0x7f6b1c134f10, ha_alter_info=0x7f6b6ed50bb0) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:7932
 
#12 0x000055f9e9565947 in handler::ha_prepare_inplace_alter_table (this=0x7f6b1c096b58, altered_table=0x7f6b1c134f10, ha_alter_info=0x7f6b6ed50bb0) at /data/src/10.4/sql/handler.cc:4437
 
#13 0x000055f9e932f516 in mysql_inplace_alter_table (thd=0x7f6b1c000b00, table_list=0x7f6b1c014e80, table=0x7f6b1c095f20, altered_table=0x7f6b1c134f10, ha_alter_info=0x7f6b6ed50bb0, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7f6b6ed50ce0, alter_ctx=0x7f6b6ed518d0) at /data/src/10.4/sql/sql_table.cc:7516
 
#14 0x000055f9e9335733 in mysql_alter_table (thd=0x7f6b1c000b00, new_db=0x7f6b1c0051b8, new_name=0x7f6b1c005588, create_info=0x7f6b6ed524c0, table_list=0x7f6b1c014e80, alter_info=0x7f6b6ed52400, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:9692
 
#15 0x000055f9e93be8bd in Sql_cmd_alter_table::execute (this=0x7f6b1c0155d8, thd=0x7f6b1c000b00) at /data/src/10.4/sql/sql_alter.cc:497
 
#16 0x000055f9e925dab4 in mysql_execute_command (thd=0x7f6b1c000b00) at /data/src/10.4/sql/sql_parse.cc:6289
 
#17 0x000055f9e92629d8 in mysql_parse (thd=0x7f6b1c000b00, rawbuf=0x7f6b1c014d98 "ALTER TABLE t1 ADD COLUMN b INT", length=31, parser_state=0x7f6b6ed53600, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8091
 
#18 0x000055f9e924fcd7 in dispatch_command (command=COM_QUERY, thd=0x7f6b1c000b00, packet=0x7f6b1c00b401 "ALTER TABLE t1 ADD COLUMN b INT", packet_length=31, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1851
 
#19 0x000055f9e924e6fb in do_command (thd=0x7f6b1c000b00) at /data/src/10.4/sql/sql_parse.cc:1396
 
#20 0x000055f9e93b8b3c in do_handle_one_connection (connect=0x55f9ec8a03e0) at /data/src/10.4/sql/sql_connect.cc:1402
 
#21 0x000055f9e93b88c0 in handle_one_connection (arg=0x55f9ec8a03e0) at /data/src/10.4/sql/sql_connect.cc:1308
 
#22 0x000055f9e98660a1 in pfs_spawn_thread (arg=0x55f9ec9256b0) at /data/src/10.4/storage/perfschema/pfs.cc:1862
 
#23 0x00007f6b7b4e7494 in start_thread (arg=0x7f6b6ed54700) at pthread_create.c:333
 
#24 0x00007f6b79ae893f in clone () from /lib/x86_64-linux-gnu/libc.so.6



 Comments   
Comment by Marko Mäkelä [ 2018-11-26 ]

In 10.3, there is no failure and the ALTER TABLE will be instantaneous, although it should not be.

The reason for this 10.3 surprise is that TRUNCATE TABLE will convert the table from (implied) ROW_FORMAT=COMPRESSED to the default ROW_FORMAT=DYNAMIC. This can be verified by adding SHOW TABLE STATUS statements.

Comment by Marko Mäkelä [ 2018-11-26 ]

On 10.2, TRUNCATE TABLE will change the ROW_FORMAT to uncompressed, but the ALTER TABLE will restore back to ROW_FORMAT=COMPRESSED.

Comment by Marko Mäkelä [ 2018-11-26 ]

This fixes it:

diff --git a/sql/table.cc b/sql/table.cc
 
index 2b278288784..0cf88aed4f6 100644
 
--- a/sql/table.cc
 
+++ b/sql/table.cc
 
@@ -3830,6 +3830,7 @@ void update_create_info_from_table(HA_CREATE_INFO *create_info, TABLE *table)
 
   create_info->table_options= share->db_create_options;
 
   create_info->avg_row_length= share->avg_row_length;
 
   create_info->row_type= share->row_type;
 
+  create_info->key_block_size= share->key_block_size;
 
   create_info->default_table_charset= share->table_charset;
 
   create_info->table_charset= 0;
 
   create_info->comment= share->comment;

In 10.4 the assertion failure would be masked by this change. The problem from the InnoDB point of view is that the ALTER TABLE is modifying ROW_FORMAT without setting ALTER_OPTIONS. This was because the two dictionaries got out of sync. I think that we should remove that assertion, and let the operation go through, without changing the ROW_FORMAT of the InnoDB table.

Comment by Marko Mäkelä [ 2018-11-26 ]

TRUNCATE will correctly preserve the KEY_BLOCK_SIZE from 10.2.20 on.
10.4.1 will remove the over-zealous debug assertions that were added in MDEV-15562 and could fail if the MariaDB and InnoDB data dictionaries are out of sync.

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