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

ER_DUP_ENTRY upon REPLACE or Assertion `transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table' failed

Details

    Description

      Note: An assertion failure with the same text was filed as MDEV-17891, but it seems to be as far as similarities go: in this case, there is no full table, no abort_result_set, no partitioning. On the other hand, there is a very odd ER_DUP_ENTRY upon REPLACE. All in all, it might still be the same problem, but it seems unlikely.

      SET TIMESTAMP=1589245268.41934;
      		 
      CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=MyISAM WITH SYSTEM VERSIONING;
      		 
      INSERT INTO t1 VALUES (1),(2);
      		 
       
      		 
      --connect (con1,localhost,root,,test)
      		 
      SET TIMESTAMP=1589245268.52093;
      		 
      REPLACE INTO t1 VALUES (1),(2);
      		 
       
      		 
      --connection default
      		 
      REPLACE INTO t1 VALUES (1),(2);
      		 
       
      		 
      --connection con1
      		 
      REPLACE INTO t1 VALUES (1),(2);

      10.3 644d9f38 non-debug build

      		 
      mysqltest: At line 14: query 'REPLACE INTO t1 VALUES (1),(2)' failed: 1062: Duplicate entry '1' for key 'PRIMARY'

      10.3 644d9f38 debug

      		 
      mysqld: /data/src/10.3/sql/sql_insert.cc:1200: bool mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool): Assertion `transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table' failed.
      		 
      200513  4:03:27 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f8d9bdaff12 in __GI___assert_fail (assertion=0x558251cfa2e0 "transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table", file=0x558251cfa0f8 "/data/src/10.3/sql/sql_insert.cc", line=1200, function=0x558251cfadc0 <mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool)::__PRETTY_FUNCTION__> "bool mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool)") at assert.c:101
      		 
      #8  0x000055825105f5d6 in mysql_insert (thd=0x7f8d78000af0, table_list=0x7f8d78011540, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_REPLACE, ignore=false) at /data/src/10.3/sql/sql_insert.cc:1199
      		 
      #9  0x00005582510a2dac in mysql_execute_command (thd=0x7f8d78000af0) at /data/src/10.3/sql/sql_parse.cc:4454
      		 
      #10 0x00005582510ae8d1 in mysql_parse (thd=0x7f8d78000af0, rawbuf=0x7f8d78011458 "REPLACE INTO t1 VALUES (1),(2)", length=30, parser_state=0x7f8d95f635e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7817
      		 
      #11 0x000055825109b13f in dispatch_command (command=COM_QUERY, thd=0x7f8d78000af0, packet=0x7f8d78008c71 "REPLACE INTO t1 VALUES (1),(2)", packet_length=30, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
      		 
      #12 0x0000558251099a57 in do_command (thd=0x7f8d78000af0) at /data/src/10.3/sql/sql_parse.cc:1401
      		 
      #13 0x0000558251211c23 in do_handle_one_connection (connect=0x55825403de20) at /data/src/10.3/sql/sql_connect.cc:1403
      		 
      #14 0x0000558251211985 in handle_one_connection (arg=0x55825403de20) at /data/src/10.3/sql/sql_connect.cc:1308
      		 
      #15 0x0000558251bc4c70 in pfs_spawn_thread (arg=0x558253f8a4e0) at /data/src/10.3/storage/perfschema/pfs.cc:1869
      		 
      #16 0x00007f8d9dd384a4 in start_thread (arg=0x7f8d95f64700) at pthread_create.c:456
      		 
      #17 0x00007f8d9be6cd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

      Reproducible on 10.3-10.5.

      Attachments

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17891 Assertion failures in select_insert::abort_result_set and mysql_load upon attempt to replace into a full table

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-22548 Assertion `0' failed in Protocol::end_statement upon multi-table DELETE IGNORE from system- and application-versioned table

          • Major - Major loss of function.
          • Confirmed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23446 UPDATE does not insert history row if the row is not changed

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Task - A task that needs to be done. MDEV-16226 TRX_ID-based System Versioning refactoring

          • Major - Major loss of function.
          • Stalled

          Task - A task that needs to be done. MDEV-24064 Utility columns for system-versioned tables

          • Major - Major loss of function.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-24451 Record retains new value on DML when history row insert fails

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            nikitamalyavin Nikita Malyavin added a comment -

            The assertion failure should be fixed by MDEV-17891 fix (https://github.com/MariaDB/server/commit/688b9de0fedfcf13c4d33e7aa98e03e6e37cb0fb)

            Though I am not sure about ER_DUP_ENTRY – it obviously fails because the same history row is inserted twice (why do you ever need two connections here, I don't know) because of the frozen timestamp.

            Maybe we should silently skip ER_DUP_ENTRY when inserting history row, I don't know. I think you can achieve the same results with UPDATE/DELETE, too.

            Isn't this `timestamp` feature for debugging/hacks purposes only?

            nikitamalyavin Nikita Malyavin added a comment - The assertion failure should be fixed by MDEV-17891 fix ( https://github.com/MariaDB/server/commit/688b9de0fedfcf13c4d33e7aa98e03e6e37cb0fb ) Though I am not sure about ER_DUP_ENTRY – it obviously fails because the same history row is inserted twice (why do you ever need two connections here, I don't know) because of the frozen timestamp. Maybe we should silently skip ER_DUP_ENTRY when inserting history row, I don't know. I think you can achieve the same results with UPDATE/DELETE, too. Isn't this `timestamp` feature for debugging/hacks purposes only?
            midenok Aleksey Midenkov added a comment -

            ER_DUP_ENTRY is expected behavior now as we must have history on every successful UPDATE (MDEV-23446). Better solution would be to have HISTORY_ID system-invisible column, but that new feature will not go to stable branch.

            midenok Aleksey Midenkov added a comment - ER_DUP_ENTRY is expected behavior now as we must have history on every successful UPDATE ( MDEV-23446 ). Better solution would be to have HISTORY_ID system-invisible column, but that new feature will not go to stable branch.

            People

              nikitamalyavin Nikita Malyavin
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.