Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-18598

Assertion `is_string == dtype_is_string_type(mtype)' failed in innobase_rename_or_enlarge_columns_cache upon MODIFY column

Details

    Description

      --source include/have_innodb.inc
      		 
       
      		 
      CREATE TABLE t1 (f TINYINT) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
      		 
      ALTER TABLE t1 MODIFY f BIT;
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t1;

      10.4 62c0ac2d

      		 
      mysqld: /data/src/10.4-bug/storage/innobase/handler/handler0alter.cc:9218: void innobase_rename_or_enlarge_columns_cache(Alter_inplace_info*, const TABLE*, const TABLE*, dict_table_t*): Assertion `is_string == dtype_is_string_type(mtype)' failed.
      		 
      190216  0:30:34 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f5ded100ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      		 
      #8  0x000055c4e2a8dbb5 in innobase_rename_or_enlarge_columns_cache (ha_alter_info=0x7f5de2404aa0, altered_table=0x7f5d9c14d6f0, table=0x7f5d9c17cb50, user_table=0x7f5d9c135968) at /data/src/10.4-bug/storage/innobase/handler/handler0alter.cc:9218
      		 
      #9  0x000055c4e2a9f85a in commit_cache_norebuild (ha_alter_info=0x7f5de2404aa0, ctx=0x7f5d9c016580, altered_table=0x7f5d9c14d6f0, table=0x7f5d9c17cb50, trx=0x7f5de2c5b268) at /data/src/10.4-bug/storage/innobase/handler/handler0alter.cc:10346
      		 
      #10 0x000055c4e2a91218 in ha_innobase::commit_inplace_alter_table (this=0x7f5d9c17d788, altered_table=0x7f5d9c14d6f0, ha_alter_info=0x7f5de2404aa0, commit=true) at /data/src/10.4-bug/storage/innobase/handler/handler0alter.cc:11029
      		 
      #11 0x000055c4e270f27a in handler::ha_commit_inplace_alter_table (this=0x7f5d9c17d788, altered_table=0x7f5d9c14d6f0, ha_alter_info=0x7f5de2404aa0, commit=true) at /data/src/10.4-bug/sql/handler.cc:4669
      		 
      #12 0x000055c4e24ae128 in mysql_inplace_alter_table (thd=0x7f5d9c000b00, table_list=0x7f5d9c0152e0, table=0x7f5d9c17cb50, altered_table=0x7f5d9c14d6f0, ha_alter_info=0x7f5de2404aa0, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7f5de2404cd0, alter_ctx=0x7f5de2405280) at /data/src/10.4-bug/sql/sql_table.cc:7605
      		 
      #13 0x000055c4e24b3f7e in mysql_alter_table (thd=0x7f5d9c000b00, new_db=0x7f5d9c0051f0, new_name=0x7f5d9c0055d8, create_info=0x7f5de2405e70, table_list=0x7f5d9c0152e0, alter_info=0x7f5de2405db0, order_num=0, order=0x0, ignore=false) at /data/src/10.4-bug/sql/sql_table.cc:9705
      		 
      #14 0x000055c4e253f622 in Sql_cmd_alter_table::execute (this=0x7f5d9c015a30, thd=0x7f5d9c000b00) at /data/src/10.4-bug/sql/sql_alter.cc:499
      		 
      #15 0x000055c4e23d6902 in mysql_execute_command (thd=0x7f5d9c000b00) at /data/src/10.4-bug/sql/sql_parse.cc:6318
      		 
      #16 0x000055c4e23dbaaa in mysql_parse (thd=0x7f5d9c000b00, rawbuf=0x7f5d9c0151f8 "ALTER TABLE t1 MODIFY f BIT", length=27, parser_state=0x7f5de24071f0, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:8129
      		 
      #17 0x000055c4e23c71e8 in dispatch_command (command=COM_QUERY, thd=0x7f5d9c000b00, packet=0x7f5d9c00a4c1 "ALTER TABLE t1 MODIFY f BIT", packet_length=27, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:1808
      		 
      #18 0x000055c4e23c5af2 in do_command (thd=0x7f5d9c000b00) at /data/src/10.4-bug/sql/sql_parse.cc:1358
      		 
      #19 0x000055c4e2539537 in do_handle_one_connection (connect=0x55c4e5ab4810) at /data/src/10.4-bug/sql/sql_connect.cc:1399
      		 
      #20 0x000055c4e25392a8 in handle_one_connection (arg=0x55c4e5ab4810) at /data/src/10.4-bug/sql/sql_connect.cc:1302
      		 
      #21 0x000055c4e2a293e3 in pfs_spawn_thread (arg=0x55c4e5b3be40) at /data/src/10.4-bug/storage/perfschema/pfs.cc:1862
      		 
      #22 0x00007f5deedd7494 in start_thread (arg=0x7f5de2408700) at pthread_create.c:333
      		 
      #23 0x00007f5ded1bd93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

      No obvious immediate effect on a non-debug build.
      Not reproducible on 10.3 and 10.4 f4f8dd69.
      10.4 a081a998 produces a different assertion failure:

      mysqld: /data/src/10.4/storage/innobase/handler/handler0alter.cc:272: void dict_table_t::prepare_instant(const dict_table_t&, const ulint*, unsigned int&): Assertion `index.fields[i].col->same_format( *oindex.fields[i].col, true)' failed.
      		 
      190216  0:36:07 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f68b893dee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      		 
      #8  0x000056314868c547 in dict_table_t::prepare_instant (this=0x7f6860048608, old=..., col_map=0x7f6860048068, first_alter_pos=@0x7f6860016678: 0) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:271
      		 
      #9  0x0000563148691b6b in ha_innobase_inplace_ctx::prepare_instant (this=0x7f6860016500) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:1072
      		 
      #10 0x000056314867c44d in prepare_inplace_alter_table_dict (ha_alter_info=0x7f68b1c63ae0, altered_table=0x7f6860152b00, old_table=0x7f6860133d60, table_name=0x7f686017cddd "t1", flags=0, 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:6545
      		 
      #11 0x0000563148681311 in ha_innobase::prepare_inplace_alter_table (this=0x7f686014f198, altered_table=0x7f6860152b00, ha_alter_info=0x7f68b1c63ae0) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:8091
      		 
      #12 0x00005631483140cb in handler::ha_prepare_inplace_alter_table (this=0x7f686014f198, altered_table=0x7f6860152b00, ha_alter_info=0x7f68b1c63ae0) at /data/src/10.4/sql/handler.cc:4649
      		 
      #13 0x00005631480a4ffc in mysql_inplace_alter_table (thd=0x7f6860000b00, table_list=0x7f6860015280, table=0x7f6860133d60, altered_table=0x7f6860152b00, ha_alter_info=0x7f68b1c63ae0, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7f68b1c63d10, alter_ctx=0x7f68b1c642c0) at /data/src/10.4/sql/sql_table.cc:7530
      		 
      #14 0x00005631480ab26c in mysql_alter_table (thd=0x7f6860000b00, new_db=0x7f68600051d0, new_name=0x7f68600055a0, create_info=0x7f68b1c64eb0, table_list=0x7f6860015280, alter_info=0x7f68b1c64df0, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:9715
      		 
      #15 0x0000563148136914 in Sql_cmd_alter_table::execute (this=0x7f68600159b0, thd=0x7f6860000b00) at /data/src/10.4/sql/sql_alter.cc:499
      		 
      #16 0x0000563147fcf3cd in mysql_execute_command (thd=0x7f6860000b00) at /data/src/10.4/sql/sql_parse.cc:6318
      		 
      #17 0x0000563147fd4570 in mysql_parse (thd=0x7f6860000b00, rawbuf=0x7f6860015198 "ALTER TABLE t1 MODIFY f BIT", length=27, parser_state=0x7f68b1c66210, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8129
      		 
      #18 0x0000563147fbfcbc in dispatch_command (command=COM_QUERY, thd=0x7f6860000b00, packet=0x7f686000a461 "ALTER TABLE t1 MODIFY f BIT", packet_length=27, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1808
      		 
      #19 0x0000563147fbe5c8 in do_command (thd=0x7f6860000b00) at /data/src/10.4/sql/sql_parse.cc:1358
      		 
      #20 0x0000563148130828 in do_handle_one_connection (connect=0x56314b05a8a0) at /data/src/10.4/sql/sql_connect.cc:1399
      		 
      #21 0x0000563148130599 in handle_one_connection (arg=0x56314b05a8a0) at /data/src/10.4/sql/sql_connect.cc:1302
      		 
      #22 0x000056314861fe75 in pfs_spawn_thread (arg=0x56314b0723a0) at /data/src/10.4/storage/perfschema/pfs.cc:1862
      		 
      #23 0x00007f68ba614494 in start_thread (arg=0x7f68b1c67700) at pthread_create.c:333
      		 
      #24 0x00007f68b89fa93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

      Attachments

        Issue Links

          is caused by

          Task - A task that needs to be done. MDEV-15563 Instant failure-free data type conversions

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            Both TINYINT and BIT are considered integer types by the SQL layer, and main.type_bit indeed demonstrates that it is an integer type, supporting up to BIT(64). This is similar to SET, which allows up to 64 members.

            For some reason, the InnoDB function get_innobase_type_from_mysql_type() maps BIT to DATA_FIXBINARY, which it also uses for CHAR BINARY. Unlike BIT, ENUM and SET map to DATA_INT.

            Both DATA_INT and DATA_FIXBINARY would be compared as binary strings. The only doubt is about the sign bit. BIT does not allow SIGNED or UNSIGNED qualifier and is internally signed. An instant conversion from BIT(8) to TINYINT is refused, but from BIT(7) it is accepted. An instant conversion to TINYINT UNSIGNED is refused (while InnoDB could allow it).

            Whlie conversions from BIT to integers seem to be fine, we definitely should not allow converting from integers to a narrower BIT. TINYINT is 8 bits, but BIT is a shorthand for BIT(1). We could allow an instantaneous conversion from TINYINT UNSIGNED to BIT(8). Conversions from signed integers to BIT are best avoided.

            While testing, I hit another regression that was introduced in MDEV-15563 for row_sel_field_store_in_mysql_format_func(): DATA_FIXBINARY should not be subject to padding with 0x20. An assertion would fail in row_mysql_pad_col().

            marko Marko Mäkelä added a comment - Both TINYINT and BIT are considered integer types by the SQL layer, and main.type_bit indeed demonstrates that it is an integer type, supporting up to BIT(64) . This is similar to SET , which allows up to 64 members. For some reason, the InnoDB function get_innobase_type_from_mysql_type() maps BIT to DATA_FIXBINARY , which it also uses for CHAR BINARY . Unlike BIT , ENUM and SET map to DATA_INT . Both DATA_INT and DATA_FIXBINARY would be compared as binary strings. The only doubt is about the sign bit. BIT does not allow SIGNED or UNSIGNED qualifier and is internally signed. An instant conversion from BIT(8) to TINYINT is refused, but from BIT(7) it is accepted. An instant conversion to TINYINT UNSIGNED is refused (while InnoDB could allow it). Whlie conversions from BIT to integers seem to be fine, we definitely should not allow converting from integers to a narrower BIT . TINYINT is 8 bits, but BIT is a shorthand for BIT(1) . We could allow an instantaneous conversion from TINYINT UNSIGNED to BIT(8) . Conversions from signed integers to BIT are best avoided. While testing, I hit another regression that was introduced in MDEV-15563 for row_sel_field_store_in_mysql_format_func() : DATA_FIXBINARY should not be subject to padding with 0x20. An assertion would fail in row_mysql_pad_col() .
            marko Marko Mäkelä added a comment -

            I think that it is simplest to disallow instant conversions between BIT and integers. We can revisit this later after testing with all storage engines.

            While testing, I found wrong-result bugs caused by MDEV-15563, which I will fix as part of this bug:

            CREATE TABLE t1 (f TINYINT) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
            		 
            INSERT INTO t1 VALUES(127),(-128);
            		 
            --enable_info
            		 
            ALTER TABLE t1 MODIFY f BIGINT DEFAULT 123456789;
            		 
            --disable_info
            		 
            SELECT * FROM t1;
            		 
            DROP TABLE t1;

            This would wrongly return 123456895, 123456896 instead of 127,-128.

            marko Marko Mäkelä added a comment - I think that it is simplest to disallow instant conversions between BIT and integers. We can revisit this later after testing with all storage engines. While testing, I found wrong-result bugs caused by MDEV-15563 , which I will fix as part of this bug: CREATE TABLE t1 (f TINYINT) ENGINE=InnoDB ROW_FORMAT=REDUNDANT; INSERT INTO t1 VALUES (127),(-128); --enable_info ALTER TABLE t1 MODIFY f BIGINT DEFAULT 123456789; --disable_info SELECT * FROM t1; DROP TABLE t1; This would wrongly return 123456895, 123456896 instead of 127,-128.

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.