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

Unexpected behavior with foreign keys or InnoDB: Failing assertion: cmp < 0

    XMLWordPrintable

Details

    Description

      --source include/have_innodb.inc
      --source include/have_sequence.inc
       
      CREATE TABLE t1 (
        id INT AUTO_INCREMENT PRIMARY KEY,
        c CHAR(120) DEFAULT '',
        k INT DEFAULT 0,
        p CHAR(60) DEFAULT ''
      ) ENGINE=InnoDB;
      INSERT INTO t1 (id) SELECT seq FROM seq_1_to_2400;
       
      CREATE TABLE t2 (
        id INT PRIMARY KEY,
        FOREIGN KEY (id) REFERENCES t1 (id)
      ) ENGINE=InnoDB;
       
      SET FOREIGN_KEY_CHECKS = OFF;
      ALTER TABLE t2 MODIFY id DOUBLE;
      SET FOREIGN_KEY_CHECKS = ON;
      ALTER TABLE t2 FORCE;
      INSERT INTO t2 (id) VALUES (1);
       
      SELECT * FROM t2;
       
      # Cleanup
      DROP TABLE t2, t1;
      

      10.5 5adcb2e7

      2021-01-25 16:49:12 4 [Warning] InnoDB: In ALTER TABLE `test`.`t2` has or is referenced in foreign key constraints which are not compatible with the new table definition.
      2021-01-25 16:49:12 0x7f62180ce700  InnoDB: Assertion failure in file /data/src/10.5/storage/innobase/row/row0ins.cc line 1781
      InnoDB: Failing assertion: cmp < 0
       
      #5  0x00007f621c973859 in __GI_abort () at abort.c:79
      #6  0x0000556482843024 in ut_dbg_assertion_failed (expr=0x556482f08f99 "cmp < 0", file=0x556482f08180 "/data/src/10.5/storage/innobase/row/row0ins.cc", line=1781) at /data/src/10.5/storage/innobase/ut/ut0dbg.cc:60
      #7  0x000055648273c135 in row_ins_check_foreign_constraint (check_ref=1, foreign=0x7f61e41e9628, table=0x7f61e405b938, entry=0x7f61e406a038, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:1781
      #8  0x000055648273c8b9 in row_ins_check_foreign_constraints (table=0x7f61e405b938, index=0x7f61e405c488, pk=true, entry=0x55648444be88, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:1982
      #9  0x0000556482740718 in row_ins_clust_index_entry (index=0x7f61e405c488, entry=0x55648444be88, thr=0x7f61e406ae60, n_ext=0) at /data/src/10.5/storage/innobase/row/row0ins.cc:3161
      #10 0x0000556482740dc4 in row_ins_index_entry (index=0x7f61e405c488, entry=0x55648444be88, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3333
      #11 0x000055648274169a in row_ins_index_entry_step (node=0x7f61e406ac30, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3502
      #12 0x0000556482741bba in row_ins (node=0x7f61e406ac30, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3661
      #13 0x00005564827424da in row_ins_step (thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3807
      #14 0x0000556482766c68 in row_insert_for_mysql (mysql_rec=0x7f61e405a538 "\377", prebuilt=0x7f61e406a738, ins_mode=ROW_INS_NORMAL) at /data/src/10.5/storage/innobase/row/row0mysql.cc:1421
      #15 0x00005564825af32d in ha_innobase::write_row (this=0x7f61e4063e60, record=0x7f61e405a538 "\377") at /data/src/10.5/storage/innobase/handler/ha_innodb.cc:7544
      #16 0x0000556482142c87 in handler::ha_write_row (this=0x7f61e4063e60, buf=0x7f61e405a538 "\377") at /data/src/10.5/sql/handler.cc:7151
      #17 0x0000556481d760f9 in write_record (thd=0x7f61e4000db8, table=0x7f61e4067038, info=0x7f62180ccbe0, sink=0x0) at /data/src/10.5/sql/sql_insert.cc:2106
      #18 0x0000556481d72e33 in mysql_insert (thd=0x7f61e4000db8, table_list=0x7f61e4014010, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false, result=0x0) at /data/src/10.5/sql/sql_insert.cc:1099
      #19 0x0000556481dc6596 in mysql_execute_command (thd=0x7f61e4000db8) at /data/src/10.5/sql/sql_parse.cc:4596
      #20 0x0000556481dd22b0 in mysql_parse (thd=0x7f61e4000db8, rawbuf=0x7f61e4013f30 "INSERT INTO t2 (id) VALUES (1)", length=30, parser_state=0x7f62180cd510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8062
      #21 0x0000556481dbe237 in dispatch_command (command=COM_QUERY, thd=0x7f61e4000db8, packet=0x7f61e40090a9 "INSERT INTO t2 (id) VALUES (1)", packet_length=30, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1889
      #22 0x0000556481dbca2b in do_command (thd=0x7f61e4000db8) at /data/src/10.5/sql/sql_parse.cc:1370
      #23 0x0000556481f6a72b in do_handle_one_connection (connect=0x5564848a9c78, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1410
      #24 0x0000556481f6a48e in handle_one_connection (arg=0x556484834238) at /data/src/10.5/sql/sql_connect.cc:1312
      #25 0x00005564824c9449 in pfs_spawn_thread (arg=0x5564847c8358) at /data/src/10.5/storage/perfschema/pfs.cc:2201
      #26 0x00007f621ce9c609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #27 0x00007f621ca70293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      The assertion failure is reproducible on 10.5/10.6, debug and release builds alike.

      Previous versions don't crash, but the behavior is still odd:

      10.2 1a999585

      SET FOREIGN_KEY_CHECKS = OFF;
      ALTER TABLE t2 MODIFY id DOUBLE;
      SET FOREIGN_KEY_CHECKS = ON;
      ALTER TABLE t2 FORCE;
      Warnings:
      Warning	1088	failed to load FOREIGN KEY constraints
      SHOW CREATE TABLE t2;
      Table	Create Table
      t2	CREATE TABLE `t2` (
        `id` double NOT NULL,
        PRIMARY KEY (`id`)
      ) ENGINE=InnoDB DEFAULT CHARSET=latin1
      INSERT INTO t2 (id) VALUES (1);
      SELECT * FROM t2;
      id
      1
      DROP TABLE t2, t1;
      

      So, even though FOREIGN_KEY_CHECKS is back ON, ALTER TABLE t2 FORCE is allowed to happen. The foreign key gets disabled (it isn't even shown in SHOW CREATE TABLE anymore), and further INSERT works without complaints.

      Both the current behavior and the assertion failure in higher versions started happening after this commit:

      commit 8268f26605c871f19cb78be08c84f621f4e0c4cb
      Author: Thirunarayanan Balathandayuthapani
      Date:   Fri Aug 7 19:02:48 2020 +0530
       
          MDEV-22934 Table disappear after two alter table command
      

      Before this patch, ALTER TABLE t2 MODIFY id DOUBLE was failing with ER_ERROR_ON_RENAME despite FOREIGN_KEY_CHECKS being OFF at that time.

      I'm not sure what is the expected behavior, disabling FOREIGN_KEY_CHECKS tends to cause controversial results. Except that it shouldn't crash or corrupt data, of course.

      Attachments

        Issue Links

          Activity

            People

              thiru Thirunarayanan Balathandayuthapani
              elenst Elena Stepanova
              Votes:
              1 Vote for this issue
              Watchers:
              6 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.