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

Assertion `num_fts_index <= 1' failed in prepare_inplace_alter_table_dict

Details

    Description

      --source include/have_innodb.inc
      		 
       
      		 
      CREATE TABLE t1 (a VARCHAR(128), b VARCHAR(128)) ENGINE=InnoDB;
      		 
      ALTER TABLE t1 ADD FULLTEXT INDEX (a);
      		 
      ALTER TABLE t1 ADD FULLTEXT INDEX (b);
      		 
      ALTER TABLE t1 ADD c SERIAL;
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t1;

      10.3 82490a97dbb

      		 
      mysqld: /data/src/10.3/storage/innobase/handler/handler0alter.cc:5457: bool prepare_inplace_alter_table_dict(Alter_inplace_info*, const TABLE*, const TABLE*, const char*, ulint, ulint, ulint, bool, bool): Assertion `num_fts_index <= 1' failed.
      		 
      190115  0:07:43 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007ff22435aee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      		 
      #8  0x000055ad5e1f6e05 in prepare_inplace_alter_table_dict (ha_alter_info=0x7ff21d69d360, altered_table=0x7ff1c80a7f40, old_table=0x7ff1c806dce0, table_name=0x7ff1c800e66d "t1", flags=33, flags2=94, fts_doc_id_col=3, add_fts_doc_id=true, add_fts_doc_id_idx=true) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:5457
      		 
      #9  0x000055ad5e1fbc10 in ha_innobase::prepare_inplace_alter_table (this=0x7ff1c800d258, altered_table=0x7ff1c80a7f40, ha_alter_info=0x7ff21d69d360) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:6998
      		 
      #10 0x000055ad5dea32cd in handler::ha_prepare_inplace_alter_table (this=0x7ff1c800d258, altered_table=0x7ff1c80a7f40, ha_alter_info=0x7ff21d69d360) at /data/src/10.3/sql/handler.cc:4436
      		 
      #11 0x000055ad5dc79bbc in mysql_inplace_alter_table (thd=0x7ff1c8000b00, table_list=0x7ff1c8014dc0, table=0x7ff1c806dce0, altered_table=0x7ff1c80a7f40, ha_alter_info=0x7ff21d69d360, inplace_supported=HA_ALTER_INPLACE_COPY_LOCK, target_mdl_request=0x7ff21d69d490, alter_ctx=0x7ff21d69e090) at /data/src/10.3/sql/sql_table.cc:7515
      		 
      #12 0x000055ad5dc7fe42 in mysql_alter_table (thd=0x7ff1c8000b00, new_db=0x7ff1c80051b8, new_name=0x7ff1c8005578, create_info=0x7ff21d69ec80, table_list=0x7ff1c8014dc0, alter_info=0x7ff21d69ebc0, order_num=0, order=0x0, ignore=false) at /data/src/10.3/sql/sql_table.cc:9700
      		 
      #13 0x000055ad5dd07ccb in Sql_cmd_alter_table::execute (this=0x7ff1c80155e8, thd=0x7ff1c8000b00) at /data/src/10.3/sql/sql_alter.cc:497
      		 
      #14 0x000055ad5dba9598 in mysql_execute_command (thd=0x7ff1c8000b00) at /data/src/10.3/sql/sql_parse.cc:6285
      		 
      #15 0x000055ad5dbae669 in mysql_parse (thd=0x7ff1c8000b00, rawbuf=0x7ff1c8014cd8 "ALTER TABLE t1 ADD c SERIAL", length=27, parser_state=0x7ff21d6a05f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8092
      		 
      #16 0x000055ad5db9b81d in dispatch_command (command=COM_QUERY, thd=0x7ff1c8000b00, packet=0x7ff1c8161121 "ALTER TABLE t1 ADD c SERIAL", packet_length=27, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1851
      		 
      #17 0x000055ad5db9a241 in do_command (thd=0x7ff1c8000b00) at /data/src/10.3/sql/sql_parse.cc:1396
      		 
      #18 0x000055ad5dd02256 in do_handle_one_connection (connect=0x55ad6045a050) at /data/src/10.3/sql/sql_connect.cc:1402
      		 
      #19 0x000055ad5dd01fda in handle_one_connection (arg=0x55ad6045a050) at /data/src/10.3/sql/sql_connect.cc:1308
      		 
      #20 0x000055ad5e19c8dd in pfs_spawn_thread (arg=0x55ad6049b940) at /data/src/10.3/storage/perfschema/pfs.cc:1862
      		 
      #21 0x00007ff226031494 in start_thread (arg=0x7ff21d6a1700) at pthread_create.c:333
      		 
      #22 0x00007ff22441793f in clone () from /lib/x86_64-linux-gnu/libc.so.6

      Both debug and non-debug builds fail.

      On 10.0-10.2 (and on upstream 5.6, 5.7) there is no assertion failure, but the error looks strange:

      mysqltest: At line 5: query 'ALTER TABLE t1 ADD c SERIAL' failed: 1795: InnoDB presently supports one FULLTEXT index creation at a time

      Note that it happens upon adding the next column, not upon adding the second FULLTEXT index.

      Attachments

        Activity

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

          Yes, InnoDB would output that obscure message whenever trying to rebuild a table that contains multiple FULLTEXT INDEX. And it is a ridiculous limitation that was introduced in MySQL 5.6 and never fixed since.

          The logic in ha_innobase::check_if_supported_inplace_alter() was broken related to MDEV-11369 or MDEV-13134. Here is a simpler test case:

          CREATE TABLE t1 (a VARCHAR(128), b VARCHAR(128), FULLTEXT INDEX(a), FULLTEXT INDEX(b)) ENGINE=InnoDB;
          		 
          ALTER TABLE t1 ADD c SERIAL;
          		 
          DROP TABLE t1;

          marko Marko Mäkelä added a comment - Yes, InnoDB would output that obscure message whenever trying to rebuild a table that contains multiple FULLTEXT INDEX . And it is a ridiculous limitation that was introduced in MySQL 5.6 and never fixed since. The logic in ha_innobase::check_if_supported_inplace_alter() was broken related to MDEV-11369 or MDEV-13134 . Here is a simpler test case: CREATE TABLE t1 (a VARCHAR (128), b VARCHAR (128), FULLTEXT INDEX (a), FULLTEXT INDEX (b)) ENGINE=InnoDB; ALTER TABLE t1 ADD c SERIAL; DROP TABLE t1;
          marko Marko Mäkelä added a comment -

          As a side effect of this fix, we again allow ALGORITHM=INPLACE to rebuild a table when one FULLTEXT INDEX survives. Also, we are returning a more accurate reason for refusing LOCK=NONE when a table with one FULLTEXT INDEX would be rebuilt:

          ERROR 0A000: LOCK=NONE is not supported. Reason: Fulltext index creation requires a lock. Try LOCK=SHARED

          marko Marko Mäkelä added a comment - As a side effect of this fix, we again allow ALGORITHM=INPLACE to rebuild a table when one FULLTEXT INDEX survives. Also, we are returning a more accurate reason for refusing LOCK=NONE when a table with one FULLTEXT INDEX would be rebuilt: ERROR 0A000: LOCK=NONE is not supported. Reason: Fulltext index creation requires a lock. Try LOCK=SHARED

          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.