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

Assertion `next_insert_id == 0' upon UPDATE on system-versioned table

    XMLWordPrintable

    Details

      Description

      Note: In the test case below, the contents of the table after UPDATE FOR PORTION is already wrong, see MDEV-22414 for it. I am not sure whether the following assertion is related to it, though.

      CREATE TABLE t1 (id INT AUTO_INCREMENT, s TIMESTAMP, e TIMESTAMP, PERIOD FOR p(s,e), PRIMARY KEY(id)) WITH SYSTEM VERSIONING;
      INSERT INTO t1 VALUES (1,'2001-09-12','2029-05-26');
      UPDATE t1 FOR PORTION OF p FROM '2004-12-20' TO '2022-07-09' SET id = 0;
      UPDATE t1 SET id = 4;
       
      # Cleanup
      DROP TABLE t1;
      

      10.4 38f6c47f

      mysqld: /data/src/10.4/sql/handler.cc:6408: int handler::ha_external_lock(THD*, int): Assertion `next_insert_id == 0' failed.
      200514 20:18:52 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f69cabfbf12 in __GI___assert_fail (assertion=0x55b18f08b287 "next_insert_id == 0", file=0x55b18f0892a9 "/data/src/10.4/sql/handler.cc", line=6408, function=0x55b18f08da40 <handler::ha_external_lock(THD*, int)::__PRETTY_FUNCTION__> "int handler::ha_external_lock(THD*, int)") at assert.c:101
      #8  0x000055b18e54f1ed in handler::ha_external_lock (this=0x7f69b41335d8, thd=0x7f69b4000af0, lock_type=2) at /data/src/10.4/sql/handler.cc:6408
      #9  0x000055b18e682c00 in unlock_external (thd=0x7f69b4000af0, table=0x7f69b4013cc0, count=1) at /data/src/10.4/sql/lock.cc:710
      #10 0x000055b18e681fff in mysql_unlock_tables (thd=0x7f69b4000af0, sql_lock=0x7f69b4013c90, free_lock=false) at /data/src/10.4/sql/lock.cc:431
      #11 0x000055b18e681f56 in mysql_unlock_tables (thd=0x7f69b4000af0, sql_lock=0x7f69b4013c90) at /data/src/10.4/sql/lock.cc:417
      #12 0x000055b18e142d52 in close_thread_tables (thd=0x7f69b4000af0) at /data/src/10.4/sql/sql_base.cc:1012
      #13 0x000055b18e1f1cd8 in mysql_execute_command (thd=0x7f69b4000af0) at /data/src/10.4/sql/sql_parse.cc:6167
      #14 0x000055b18e1f6b4d in mysql_parse (thd=0x7f69b4000af0, rawbuf=0x7f69b4013198 "UPDATE t1 SET id = 4", length=20, parser_state=0x7f69c4da5570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7900
      #15 0x000055b18e1e30fd in dispatch_command (command=COM_QUERY, thd=0x7f69b4000af0, packet=0x7f69b4136221 "UPDATE t1 SET id = 4", packet_length=20, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
      #16 0x000055b18e1e189f in do_command (thd=0x7f69b4000af0) at /data/src/10.4/sql/sql_parse.cc:1360
      #17 0x000055b18e369458 in do_handle_one_connection (connect=0x55b191b53cf0) at /data/src/10.4/sql/sql_connect.cc:1412
      #18 0x000055b18e3691a7 in handle_one_connection (arg=0x55b191b53cf0) at /data/src/10.4/sql/sql_connect.cc:1316
      #19 0x000055b18ed6946b in pfs_spawn_thread (arg=0x55b191b6fbf0) at /data/src/10.4/storage/perfschema/pfs.cc:1869
      #20 0x00007f69ccb844a4 in start_thread (arg=0x7f69c4da6700) at pthread_create.c:456
      #21 0x00007f69cacb8d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      Reproducible on 10.4-10.5 with at least MyISAM and InnoDB.
      The test case is not applicable to 10.3.
      Non-debug build doesn't crash or produce anything obviously unexpected upon the last UPDATE, but wrong contents caused by MDEV-22414 is present there as well.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              midenok Aleksey Midenkov
              Reporter:
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: