Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3.10, 10.4.0, 10.2.19
-
None
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
|
Attachments
Issue Links
- relates to
-
MDEV-11369 Instant add column for InnoDB
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
On 10.2, TRUNCATE TABLE will change the ROW_FORMAT to uncompressed, but the ALTER TABLE will restore back to ROW_FORMAT=COMPRESSED.
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.
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.
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.