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

InnoDB: dict_load_foreigns() returned 38 and Failing assertion: 0 in ha_innodb::commit_inplace_alter_table

    XMLWordPrintable

    Details

      Description

      Run with --repeat if it doesn't fail right away.

      --source include/have_innodb.inc
       
      --connect (con1,localhost,root,,test)
      CREATE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB;
      INSERT INTO t1 VALUES (45852),(19898),(55954);
      CREATE TABLE t2 (pk INT PRIMARY KEY, FOREIGN KEY (pk) REFERENCES t1 (pk) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB;
      --send
        ALTER TABLE t1 FORCE;
       
      --connection default
      ALTER TABLE t2 FORCE;
       
      # Cleanup
       
      --connection con1
      --reap
      --disconnect con1
      --connection default
      DROP TABLE t2, t1;
      

      10.1 36ea82617c

      2018-07-02  0:48:46 140626074102528 [ERROR] InnoDB: dict_load_foreigns() returned 38 for ALTER TABLE t2 FORCE
      2018-07-02 00:48:46 7fe60f316b00  InnoDB: Assertion failure in thread 140626074102528 in file handler0alter.cc line 6163
      InnoDB: Failing assertion: 0
       
      #5  0x00007fe60d2aa3fa in abort () from /lib/x86_64-linux-gnu/libc.so.6
      #6  0x00007fe60671c3c4 in ha_innodb::commit_inplace_alter_table (this=0x7fe5f70b0888, altered_table=0x7fe5f71e7070, ha_alter_info=0x7fe60f312b00, commit=true) at /data/src/10.1/storage/innobase/handler/handler0alter.cc:6163
      #7  0x000055c2322fd991 in handler::ha_commit_inplace_alter_table (this=0x7fe5f70b0888, altered_table=0x7fe5f71e7070, ha_alter_info=0x7fe60f312b00, commit=true) at /data/src/10.1/sql/handler.cc:4222
      #8  0x000055c23217a0cc in mysql_inplace_alter_table (thd=0x7fe603bc7070, table_list=0x7fe5f7043160, table=0x7fe5f7081c70, altered_table=0x7fe5f71e7070, ha_alter_info=0x7fe60f312b00, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7fe60f312b70, alter_ctx=0x7fe60f313710) at /data/src/10.1/sql/sql_table.cc:7222
      #9  0x000055c23217ea3c in mysql_alter_table (thd=0x7fe603bc7070, new_db=0x7fe5f7043750 "test", new_name=0x0, create_info=0x7fe60f314300, table_list=0x7fe5f7043160, alter_info=0x7fe60f314270, order_num=0, order=0x0, ignore=false) at /data/src/10.1/sql/sql_table.cc:9048
      #10 0x000055c2321efc9b in Sql_cmd_alter_table::execute (this=0x7fe5f7043758, thd=0x7fe603bc7070) at /data/src/10.1/sql/sql_alter.cc:325
      #11 0x000055c2320bf441 in mysql_execute_command (thd=0x7fe603bc7070) at /data/src/10.1/sql/sql_parse.cc:5696
      #12 0x000055c2320c3bcb in mysql_parse (thd=0x7fe603bc7070, rawbuf=0x7fe5f7043088 "ALTER TABLE t2 FORCE", length=20, parser_state=0x7fe60f3155e0) at /data/src/10.1/sql/sql_parse.cc:7449
      #13 0x000055c2320b2605 in dispatch_command (command=COM_QUERY, thd=0x7fe603bc7070, packet=0x7fe605ac3071 "ALTER TABLE t2 FORCE", packet_length=20) at /data/src/10.1/sql/sql_parse.cc:1492
      #14 0x000055c2320b138a in do_command (thd=0x7fe603bc7070) at /data/src/10.1/sql/sql_parse.cc:1121
      #15 0x000055c2321eb22d in do_handle_one_connection (thd_arg=0x7fe603bc7070) at /data/src/10.1/sql/sql_connect.cc:1330
      #16 0x000055c2321eaf91 in handle_one_connection (arg=0x7fe603bc7070) at /data/src/10.1/sql/sql_connect.cc:1242
      #17 0x000055c2325a8452 in pfs_spawn_thread (arg=0x7fe607ff2670) at /data/src/10.1/storage/perfschema/pfs.cc:1861
      #18 0x00007fe60efa5494 in start_thread (arg=0x7fe60f316b00) at pthread_create.c:333
      #19 0x00007fe60d35e93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      Couldn't reproduce on 10.0 or 10.2.
      No obvious problems on a non-debug build.

      Search for the error 38 in dict_load_foreigns gave me only one result:
      https://bugs.launchpad.net/percona-server/+bug/1385060 . The test case from this bug report doesn't fail for me, though.

      This bug points at the upstream bug https://bugs.mysql.com/bug.php?id=74363 .

      However, that bug describes a different error in a different place. I suppose there was a reason why the Percona entry says it's the same, but this reason is unknown to me. I hope Marko Mäkelä will remember it, as he was looking into the upstream issue at the time.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: