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

Assertion `fields[i].same(instant.fields[i])' failed in dict_index_t::instant_add_field #2

Details

    Description

      The fix for MDEV-22771 is already in the branch.

      --source include/have_innodb.inc
      		 
       
      		 
      SET @row_format.save= @@innodb_default_row_format;
      		 
       
      		 
      CREATE TABLE t1 (a char(8)) ENGINE=InnoDB DEFAULT CHARSET utf8;
      		 
      SET GLOBAL innodb_default_row_format= REDUNDANT;
      		 
      ALTER TABLE t1 ADD b INT;
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t1;
      		 
      SET GLOBAL innodb_default_row_format= @row_format.save;

      10.4 05d62518

      		 
      mysqld: /data/src/10.4/storage/innobase/handler/handler0alter.cc:466: void dict_index_t::instant_add_field(const dict_index_t&): Assertion `fields[i].same(instant.fields[i])' failed.
      		 
      200727  1:03:56 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007fcdde30af12 in __GI___assert_fail (assertion=0x55fc5f086c98 "fields[i].same(instant.fields[i])", file=0x55fc5f086348 "/data/src/10.4/storage/innobase/handler/handler0alter.cc", line=466, function=0x55fc5f08f300 <dict_index_t::instant_add_field(dict_index_t const&)::__PRETTY_FUNCTION__> "void dict_index_t::instant_add_field(const dict_index_t&)") at assert.c:101
      		 
      #8  0x000055fc5e76ca90 in dict_index_t::instant_add_field (this=0x7fcd8c1583a0, instant=...) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:466
      		 
      #9  0x000055fc5e76e9ec in dict_table_t::instant_column (this=0x7fcd8c19ff10, table=..., col_map=0x7fcd8c16b340) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:636
      		 
      #10 0x000055fc5e771129 in ha_innobase_inplace_ctx::instant_column (this=0x7fcd8c014800) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:1086
      		 
      #11 0x000055fc5e74f28c in innobase_instant_try (ha_alter_info=0x7fcdd36afd50, ctx=0x7fcd8c014800, altered_table=0x7fcdd36afdf0, table=0x7fcd8c158be0, trx=0x7fcdd814d268) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:5708
      		 
      #12 0x000055fc5e774b93 in commit_try_norebuild (ha_alter_info=0x7fcdd36afd50, ctx=0x7fcd8c014800, altered_table=0x7fcdd36afdf0, old_table=0x7fcd8c158be0, trx=0x7fcdd814d268, table_name=0x7fcd8c1a17c5 "t1") at /data/src/10.4/storage/innobase/handler/handler0alter.cc:10254
      		 
      #13 0x000055fc5e762399 in ha_innobase::commit_inplace_alter_table (this=0x7fcd8c19f718, altered_table=0x7fcdd36afdf0, ha_alter_info=0x7fcdd36afd50, commit=true) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:11006
      		 
      #14 0x000055fc5e4cd429 in handler::ha_commit_inplace_alter_table (this=0x7fcd8c19f718, altered_table=0x7fcdd36afdf0, ha_alter_info=0x7fcdd36afd50, commit=true) at /data/src/10.4/sql/handler.cc:4616
      		 
      #15 0x000055fc5e25511f in mysql_inplace_alter_table (thd=0x7fcd8c000af0, table_list=0x7fcd8c013278, table=0x7fcd8c158be0, altered_table=0x7fcdd36afdf0, ha_alter_info=0x7fcdd36afd50, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7fcdd36b0bc0, alter_ctx=0x7fcdd36b1700) at /data/src/10.4/sql/sql_table.cc:7797
      		 
      #16 0x000055fc5e25bdce in mysql_alter_table (thd=0x7fcd8c000af0, new_db=0x7fcd8c0052b0, new_name=0x7fcd8c0056b8, create_info=0x7fcdd36b22f0, table_list=0x7fcd8c013278, alter_info=0x7fcdd36b2230, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10156
      		 
      #17 0x000055fc5e2f40f1 in Sql_cmd_alter_table::execute (this=0x7fcd8c013a60, thd=0x7fcd8c000af0) at /data/src/10.4/sql/sql_alter.cc:520
      		 
      #18 0x000055fc5e1717a0 in mysql_execute_command (thd=0x7fcd8c000af0) at /data/src/10.4/sql/sql_parse.cc:6098
      		 
      #19 0x000055fc5e176c91 in mysql_parse (thd=0x7fcd8c000af0, rawbuf=0x7fcd8c013198 "ALTER TABLE t1 ADD b INT", length=24, parser_state=0x7fcdd36b3570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7896
      		 
      #20 0x000055fc5e1631c6 in dispatch_command (command=COM_QUERY, thd=0x7fcd8c000af0, packet=0x7fcd8c0083a1 "ALTER TABLE t1 ADD b INT", packet_length=24, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1835
      		 
      #21 0x000055fc5e161968 in do_command (thd=0x7fcd8c000af0) at /data/src/10.4/sql/sql_parse.cc:1353
      		 
      #22 0x000055fc5e2eab0c in do_handle_one_connection (connect=0x55fc61035760) at /data/src/10.4/sql/sql_connect.cc:1412
      		 
      #23 0x000055fc5e2ea85b in handle_one_connection (arg=0x55fc61035760) at /data/src/10.4/sql/sql_connect.cc:1316
      		 
      #24 0x000055fc5ecea879 in pfs_spawn_thread (arg=0x55fc610515f0) at /data/src/10.4/storage/perfschema/pfs.cc:1869
      		 
      #25 0x00007fcde02934a4 in start_thread (arg=0x7fcdd36b4700) at pthread_create.c:456
      		 
      #26 0x00007fcdde3c7d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

      Not reproducible on 10.3.
      No obvious problem on a non-debug build.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17831 Assertion `supports_instant()' failed in dict_table_t::prepare_instant upon ADD COLUMN on table with KEY_BLOCK_SIZE

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-22771 Assertion `fields[i].same(instant.fields[i])' failed in dict_index_t::instant_add_field

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23345 Assertion `not_redundant() == old.not_redundant()' failed in dict_table_t::prepare_instant

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-24758 ASAN use-after-poison in ut_memcpy / page_cur_insert_rec_low

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26577 InnoDB: Failing assertion: dict_tf2_is_valid(flags, flags2) during ADD COLUMN

          • 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 -

            The problem seems to be that the dummy table object instant.table was created in ROW_FORMAT=REDUNDANT instead of the current ROW_FORMAT of the table. There are two possible fixes:

            • Ignore the global parameter and preserve the table in the original ROW_FORMAT.
            • Refuse the ALGORITHM=INSTANT operation because the ROW_FORMAT would change.

            This bug demonstrates how problematic it is to introduce global parameters that affect DDL operations. We also face the challenge that the global parameter could be modified between the time we checked it in ha_innobase::check_if_supported_inplace_alter() and again in prepare_inplace_alter_table_dict(). We might first confirm that an ALGORITHM=INSTANT operation is possible, but then find out that the ROW_FORMAT change actually requires that the table be rebuilt.

            marko Marko Mäkelä added a comment - The problem seems to be that the dummy table object instant.table was created in ROW_FORMAT=REDUNDANT instead of the current ROW_FORMAT of the table. There are two possible fixes: Ignore the global parameter and preserve the table in the original ROW_FORMAT . Refuse the ALGORITHM=INSTANT operation because the ROW_FORMAT would change. This bug demonstrates how problematic it is to introduce global parameters that affect DDL operations. We also face the challenge that the global parameter could be modified between the time we checked it in ha_innobase::check_if_supported_inplace_alter() and again in prepare_inplace_alter_table_dict() . We might first confirm that an ALGORITHM=INSTANT operation is possible, but then find out that the ROW_FORMAT change actually requires that the table be rebuilt.
            marko Marko Mäkelä added a comment -

            It would be consistent with the MDEV-17831 fix to preserve the existing ROW_FORMAT in dict_table_t::prepare_instant().

            marko Marko Mäkelä added a comment - It would be consistent with the MDEV-17831 fix to preserve the existing ROW_FORMAT in dict_table_t::prepare_instant() .
            marko Marko Mäkelä added a comment -

            In dict_table_t::prepare_instant() we definitely do not support changing the ROW_FORMAT between REDUNDANT and DYNAMIC or COMPACT. Some assertions will be needed.

            I think that it is most consistent to remember the return value of handler::check_if_supported_inplace_alter() and to preserve the ROW_FORMAT in ha_innobase::prepare_inplace_alter_table() if ALGORITHM=INSTANT had been promised.

            I used the following test case to test my fix. It is returning the correct ROW_FORMAT for all 3 combinations in 10.3:

            --source include/have_innodb.inc
            		 
            --source include/innodb_row_format.inc
            		 
            SET @row_format.save= @@innodb_default_row_format;
            		 
            CREATE TABLE t1 (a char(8)) ENGINE=InnoDB DEFAULT CHARSET utf8;
            		 
            SET GLOBAL innodb_default_row_format= COMPACT;
            		 
            ALTER TABLE t1 ADD b INT;
            		 
            SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME='t1';
            		 
            DROP TABLE t1;
            		 
            SET GLOBAL innodb_default_row_format= @row_format.save;

            If I omit my actual fix, the 2 added assertions in dict_table_t::prepare_instant() would fail.

            marko Marko Mäkelä added a comment - In dict_table_t::prepare_instant() we definitely do not support changing the ROW_FORMAT between REDUNDANT and DYNAMIC or COMPACT . Some assertions will be needed. I think that it is most consistent to remember the return value of handler::check_if_supported_inplace_alter() and to preserve the ROW_FORMAT in ha_innobase::prepare_inplace_alter_table() if ALGORITHM=INSTANT had been promised. I used the following test case to test my fix. It is returning the correct ROW_FORMAT for all 3 combinations in 10.3: --source include/have_innodb.inc --source include/innodb_row_format.inc SET @row_format.save= @@innodb_default_row_format; CREATE TABLE t1 (a char (8)) ENGINE=InnoDB DEFAULT CHARSET utf8; SET GLOBAL innodb_default_row_format= COMPACT; ALTER TABLE t1 ADD b INT ; SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME= 't1' ; DROP TABLE t1; SET GLOBAL innodb_default_row_format= @row_format.save; If I omit my actual fix, the 2 added assertions in dict_table_t::prepare_instant() would fail.
            nikitamalyavin Nikita Malyavin added a comment -

            the sql-side changes are fine, now it's Thiru's turn

            nikitamalyavin Nikita Malyavin added a comment - the sql-side changes are fine, now it's Thiru's turn

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.