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

Assertion `m_status == DA_ERROR' failed in Diagnostics_area::sql_errno on SAVEPOINT, Got error 1, Got error 153, Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.

Details

    Description

      SET unique_checks=0,foreign_key_checks=0,autocommit=0;
      CREATE TABLE t (c INT KEY) ENGINE=InnoDB;
      INSERT INTO t VALUES (0,0);
      SAVEPOINT a;
      INSERT INTO t VALUES (0),(0);
      SAVEPOINT a;
      

      Leads to (please note the differences in output 10.11 dbg vs opt and 10.6 dbg, note also different crash in 10.6 dbg only):

      10.11.1 50c5743adc87e1cdec1431a02558f6540fe5a6d5 (Optimized)

      10.11.0-opt>INSERT INTO t VALUES (0,0);
      ERROR 1136 (21S01): Column count doesn't match value count at row 1
      10.11.0-opt>SAVEPOINT a;
      Query OK, 0 rows affected (0.000 sec)
       
      10.11.0-opt>INSERT INTO t VALUES (0),(0);
      ERROR 1180 (HY000): Got error 1 "Operation not permitted" during COMMIT
      10.11.0-opt>SAVEPOINT a;
      ERROR 1030 (HY000): Got error 153 "No savepoint with that name" from storage engine InnoDB
      

      10.11.1 50c5743adc87e1cdec1431a02558f6540fe5a6d5 (Debug)

      10.11.1-dbg>INSERT INTO t VALUES (0,0);
      ERROR 1136 (21S01): Column count doesn't match value count at row 1
      10.11.1-dbg>SAVEPOINT a;
      Query OK, 0 rows affected (0.000 sec)
       
      10.11.1-dbg>INSERT INTO t VALUES (0),(0);
      ERROR 1180 (HY000): Got error 1 "Operation not permitted" during COMMIT
      10.11.1-dbg>SAVEPOINT a;
      ERROR 2013 (HY000): Lost connection to server during query
      

      10.6.10 5e270ca28d05acb72c6aec9f1d37f9610fc11a0e (Debug)

      10.6.10-dbg>INSERT INTO t VALUES (0,0);
      ERROR 1136 (21S01): Column count doesn't match value count at row 1
      10.6.10-dbg>SAVEPOINT a;
      Query OK, 0 rows affected (0.000 sec)
       
      10.6.10-dbg>INSERT INTO t VALUES (0),(0);
      ERROR 1062 (23000): Duplicate entry '0' for key 'PRIMARY'
      10.6.10-dbg>SAVEPOINT a;
      ERROR 2013 (HY000): Lost connection to server during query
      

      10.11.1 50c5743adc87e1cdec1431a02558f6540fe5a6d5 (Debug)

      mysqld: /test/10.11_dbg/sql/sql_error.h:1052: uint Diagnostics_area::sql_errno() const: Assertion `m_status == DA_ERROR' failed.
      

      10.11.1 50c5743adc87e1cdec1431a02558f6540fe5a6d5 (Debug)

      Core was generated by `/test/MD221022-mariadb-10.11.1-linux-x86_64-dbg/bin/mysqld --no-defaults --core'.
      Program terminated with signal SIGABRT, Aborted.
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      [Current thread is 1 (Thread 0x14f950d35700 (LWP 2679047))]
      (gdb) bt
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      #1  0x000014f97baf7859 in __GI_abort () at abort.c:79
      #2  0x000014f97baf7729 in __assert_fail_base (fmt=0x14f97bc8d588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55b4007d514c "m_status == DA_ERROR", file=0x55b4007c9a08 "/test/10.11_dbg/sql/sql_error.h", line=1052, function=<optimized out>) at assert.c:92
      #3  0x000014f97bb08fd6 in __GI___assert_fail (assertion=assertion@entry=0x55b4007d514c "m_status == DA_ERROR", file=file@entry=0x55b4007c9a08 "/test/10.11_dbg/sql/sql_error.h", line=line@entry=1052, function=function@entry=0x55b4007d0830 "uint Diagnostics_area::sql_errno() const") at assert.c:101
      #4  0x000055b3ffbc1145 in Diagnostics_area::sql_errno (this=0x14f8cc006c50) at /test/10.11_dbg/sql/sql_error.h:1052
      #5  thd_get_error_number (thd=<optimized out>) at /test/10.11_dbg/sql/sql_class.cc:540
      #6  0x000055b40041e3da in trx_state_eq (relaxed=true, state=TRX_STATE_ACTIVE, trx=0x14f973391b80) at /test/10.11_dbg/storage/innobase/include/trx0trx.inl:65
      #7  trx_release_savepoint_for_mysql (trx=trx@entry=0x14f973391b80, savepoint_name=savepoint_name@entry=0x14f950d33b50 "8692IDQQ0") at /test/10.11_dbg/storage/innobase/trx/trx0roll.cc:552
      #8  0x000055b4001fcd89 in innobase_release_savepoint (hton=<optimized out>, thd=<optimized out>, savepoint=0x14f8cc017288) at /test/10.11_dbg/storage/innobase/handler/ha_innodb.cc:4875
      #9  0x000055b3fff12978 in ha_release_savepoint (thd=thd@entry=0x14f8cc000d48, sv=sv@entry=0x14f8cc017250) at /test/10.11_dbg/sql/handler.cc:2967
      #10 0x000055b3ffda26a8 in trans_savepoint (thd=thd@entry=0x14f8cc000d48, name=<optimized out>) at /test/10.11_dbg/sql/transaction.cc:599
      #11 0x000055b3ffc38850 in mysql_execute_command (thd=thd@entry=0x14f8cc000d48, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.11_dbg/sql/sql_parse.cc:5705
      #12 0x000055b3ffc21f90 in mysql_parse (thd=thd@entry=0x14f8cc000d48, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14f950d34300) at /test/10.11_dbg/sql/sql_parse.cc:8023
      #13 0x000055b3ffc2f4ac in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14f8cc000d48, packet=packet@entry=0x14f8cc00af09 "SAVEPOINT a", packet_length=packet_length@entry=11, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_class.h:1346
      #14 0x000055b3ffc318f4 in do_command (thd=0x14f8cc000d48, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_parse.cc:1407
      #15 0x000055b3ffd8e067 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55b4022edf28, put_in_cache=put_in_cache@entry=true) at /test/10.11_dbg/sql/sql_connect.cc:1416
      #16 0x000055b3ffd8e536 in handle_one_connection (arg=0x55b4022edf28) at /test/10.11_dbg/sql/sql_connect.cc:1318
      #17 0x000014f97c008609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #18 0x000014f97bbf4133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      10.6.10 5e270ca28d05acb72c6aec9f1d37f9610fc11a0e (Debug)

      mysqld: /test/10.6_dbg/sql/sql_error.cc:334: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
      

      10.6.10 5e270ca28d05acb72c6aec9f1d37f9610fc11a0e (Debug)

      Core was generated by `/test/MD190922-mariadb-10.6.10-linux-x86_64-dbg/bin/mysqld --no-defaults --core'.
      Program terminated with signal SIGABRT, Aborted.
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      [Current thread is 1 (Thread 0x147f040e2700 (LWP 4017024))]
      (gdb) bt
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      #1  0x0000147f328b7859 in __GI_abort () at abort.c:79
      #2  0x0000147f328b7729 in __assert_fail_base (fmt=0x147f32a4d588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55b812b1e0c8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x55b812b1dfa8 "/test/10.6_dbg/sql/sql_error.cc", line=334, function=<optimized out>) at assert.c:92
      #3  0x0000147f328c8fd6 in __GI___assert_fail (assertion=assertion@entry=0x55b812b1e0c8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=file@entry=0x55b812b1dfa8 "/test/10.6_dbg/sql/sql_error.cc", line=line@entry=334, function=function@entry=0x55b812b1e100 "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:101
      #4  0x000055b811f09109 in Diagnostics_area::set_ok_status (this=0x147e900069c0, affected_rows=affected_rows@entry=0, last_insert_id=last_insert_id@entry=0, message=message@entry=0x0) at /test/10.6_dbg/sql/sql_error.h:1036
      #5  0x000055b811f6171d in my_ok (message=0x0, id=0, affected_rows_arg=0, thd=0x147e90000d48) at /test/10.6_dbg/sql/sql_class.h:5607
      #6  mysql_execute_command (thd=thd@entry=0x147e90000d48, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.6_dbg/sql/sql_parse.cc:5701
      #7  0x000055b811f4aa3d in mysql_parse (thd=thd@entry=0x147e90000d48, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x147f040e1330) at /test/10.6_dbg/sql/sql_parse.cc:8030
      #8  0x000055b811f5815a in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x147e90000d48, packet=packet@entry=0x147e9000ac49 "SAVEPOINT a", packet_length=packet_length@entry=11, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_class.h:1364
      #9  0x000055b811f5a880 in do_command (thd=0x147e90000d48, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_parse.cc:1409
      #10 0x000055b8120a4a11 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55b814b90568, put_in_cache=put_in_cache@entry=true) at /test/10.6_dbg/sql/sql_connect.cc:1416
      #11 0x000055b8120a4f1b in handle_one_connection (arg=0x55b814b90568) at /test/10.6_dbg/sql/sql_connect.cc:1318
      #12 0x0000147f32dc8609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #13 0x0000147f329b4133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Crash confirmed present in:
      MariaDB: 10.6.10 (dbg) (different crash), 10.7.6 (dbg), 10.8.5 (dbg), 10.9.3 (dbg), 10.10.2 (dbg), 10.11.1 (dbg)

      Also affected:
      MariaDB: 10.6.10 (opt), 10.7.6 (opt), 10.8.5 (opt), 10.9.3 (opt), 10.10.2 (opt), 10.11.1 (opt)

      Bug (or feature/syntax) confirmed not present in:
      MariaDB: 10.3.37 (dbg), 10.3.37 (opt), 10.4.27 (dbg), 10.4.27 (opt), 10.5.18 (dbg), 10.5.18 (opt), 10.6.10 (opt), 10.7.6 (opt), 10.8.5 (opt), 10.9.3 (opt), 10.10.2 (opt), 10.11.1 (opt)
      MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.38 (dbg), 5.7.38 (opt), 8.0.29 (dbg), 8.0.29 (opt)

      Attachments

        Issue Links

          Activity

            SET sql_mode='',unique_checks=0,foreign_key_checks=0,autocommit=0;
            CREATE PROCEDURE p (OUT i INT) MODIFIES SQL DATA SAVEPOINT p;
            CREATE TABLE t1 (a INT) ENGINE=InnoDB;
            INSERT INTO t1 VALUES ();
            SAVEPOINT p;
            CREATE TEMPORARY TABLE t2 (i INT KEY) ENGINE=InnoDB;
            INSERT INTO t2 VALUES(),();
            CALL p (@b);
            

            Leads to:

            11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Optimized)

            11.0.1-opt>INSERT INTO t2 VALUES(),();
            ERROR 1062 (23000): Duplicate entry '0' for key 'PRIMARY'
            11.0.1-opt>CALL p (@b);
            ERROR 1030 (HY000): Got error 153 "No savepoint with that name" from storage engine InnoDB
            

            On optimized builds. On debug it crashes:

            11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Debug)

            mariadbd: /test/11.0_dbg/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
            

            11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Debug)

            Core was generated by `/test/MD180223-mariadb-11.0.1-linux-x86_64-dbg/bin/mariadbd --no-defaults --cor'.
            Program terminated with signal SIGABRT, Aborted.
            #0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=22754753246784)
                at ./nptl/pthread_kill.c:44
            [Current thread is 1 (Thread 0x14b200fbf640 (LWP 4047030))]
            (gdb) bt
            #0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=22754753246784) at ./nptl/pthread_kill.c:44
            #1  __pthread_kill_internal (signo=6, threadid=22754753246784) at ./nptl/pthread_kill.c:78
            #2  __GI___pthread_kill (threadid=22754753246784, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
            #3  0x000014b21a661476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
            #4  0x000014b21a6477f3 in __GI_abort () at ./stdlib/abort.c:79
            #5  0x000014b21a64771b in __assert_fail_base (fmt=0x14b21a7fc150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55674898fd78 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x55674898fc58 "/test/11.0_dbg/sql/sql_error.cc", line=335, function=<optimized out>) at ./assert/assert.c:92
            #6  0x000014b21a658e96 in __GI___assert_fail (assertion=0x55674898fd78 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x55674898fc58 "/test/11.0_dbg/sql/sql_error.cc", line=335, function=0x55674898fdb0 "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at ./assert/assert.c:101
            #7  0x0000556747e41577 in Diagnostics_area::set_ok_status (this=0x14b1b4006b60, affected_rows=affected_rows@entry=0, last_insert_id=last_insert_id@entry=0, message=message@entry=0x0) at /test/11.0_dbg/sql/sql_error.cc:335
            #8  0x0000556747e90191 in my_ok (message=0x0, id=0, affected_rows_arg=0, thd=0x14b1b4000d58) at /test/11.0_dbg/sql/sql_class.h:4426
            #9  mysql_execute_command (thd=0x14b1b4000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/11.0_dbg/sql/sql_parse.cc:5713
            #10 0x0000556747dc93c2 in sp_instr_stmt::exec_core (this=0x14b1b408c960, thd=<optimized out>, nextp=0x14b200fbd374) at /test/11.0_dbg/sql/sp_head.cc:3857
            #11 0x0000556747dd65d4 in sp_lex_keeper::reset_lex_and_exec_core (this=this@entry=0x14b1b408c9a8, thd=thd@entry=0x14b1b4000d58, nextp=nextp@entry=0x14b200fbd374, open_tables=open_tables@entry=false, instr=instr@entry=0x14b1b408c960) at /test/11.0_dbg/sql/sp_head.cc:3582
            #12 0x0000556747dd6d43 in sp_instr_stmt::execute (this=0x14b1b408c960, thd=0x14b1b4000d58, nextp=0x14b200fbd374) at /test/11.0_dbg/sql/sp_head.cc:3763
            #13 0x0000556747dcf338 in sp_head::execute (this=this@entry=0x14b1b408b930, thd=thd@entry=0x14b1b4000d58, merge_da_on_success=merge_da_on_success@entry=true) at /test/11.0_dbg/sql/sp_head.cc:1459
            #14 0x0000556747dd15da in sp_head::execute_procedure (this=0x14b1b408b930, thd=thd@entry=0x14b1b4000d58, args=0x14b1b4005ed8) at /test/11.0_dbg/sql/sp_head.cc:2446
            #15 0x0000556747e7f473 in do_execute_sp (thd=thd@entry=0x14b1b4000d58, sp=sp@entry=0x14b1b408b930) at /test/11.0_dbg/sql/sql_parse.cc:3026
            #16 0x0000556747e83c00 in Sql_cmd_call::execute (this=0x14b1b40131f0, thd=0x14b1b4000d58) at /test/11.0_dbg/sql/sql_parse.cc:3271
            #17 0x0000556747e90db6 in mysql_execute_command (thd=thd@entry=0x14b1b4000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/11.0_dbg/sql/sql_parse.cc:6003
            #18 0x0000556747e927cf in mysql_parse (thd=thd@entry=0x14b1b4000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14b200fbe2c0) at /test/11.0_dbg/sql/sql_parse.cc:8002
            #19 0x0000556747e94963 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14b1b4000d58, packet=packet@entry=0x14b1b400ae19 "CALL p (@b)", packet_length=packet_length@entry=11, blocking=blocking@entry=true) at /test/11.0_dbg/sql/sql_class.h:242
            #20 0x0000556747e967bc in do_command (thd=0x14b1b4000d58, blocking=blocking@entry=true) at /test/11.0_dbg/sql/sql_parse.cc:1407
            #21 0x0000556747fe76e2 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55674aa26d58, put_in_cache=put_in_cache@entry=true) at /test/11.0_dbg/sql/sql_connect.cc:1416
            #22 0x0000556747fe7941 in handle_one_connection (arg=0x55674aa26d58) at /test/11.0_dbg/sql/sql_connect.cc:1318
            #23 0x000014b21a6b3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
            #24 0x000014b21a745a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
            

            Confirmed the crash in 10.6-11.0 (dbg), and the error message in 10.6-11.0 (opt). 10.5 Does not look to be affected.

            If we remove TEMPORARY from the testcase for t2, we get:

            11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Debug)

            11.0.1-dbg>INSERT INTO t2 VALUES(),();
            ERROR 1180 (HY000): Got error 1 "Operation not permitted" during COMMIT
            11.0.1-dbg>CALL p (@b);
            Query OK, 0 rows affected (0.000 sec)
            

            Any non-affected version will produce (with and without TEMPORARY):

            10.5.20 c41c79650aa2ef8eaf3f887b94db8cc7478eadd1 (Optimized)

            10.5.20-opt>INSERT INTO t2 VALUES(),();
            ERROR 1062 (23000): Duplicate entry '0' for key 'PRIMARY'
            10.5.20-opt>CALL p (@b);
            Query OK, 0 rows affected (0.001 sec)
            

            Roel Roel Van de Paar added a comment - SET sql_mode= '' ,unique_checks=0,foreign_key_checks=0,autocommit=0; CREATE PROCEDURE p ( OUT i INT ) MODIFIES SQL DATA SAVEPOINT p; CREATE TABLE t1 (a INT ) ENGINE=InnoDB; INSERT INTO t1 VALUES (); SAVEPOINT p; CREATE TEMPORARY TABLE t2 (i INT KEY ) ENGINE=InnoDB; INSERT INTO t2 VALUES (),(); CALL p (@b); Leads to: 11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Optimized) 11.0.1-opt>INSERT INTO t2 VALUES(),(); ERROR 1062 (23000): Duplicate entry '0' for key 'PRIMARY' 11.0.1-opt>CALL p (@b); ERROR 1030 (HY000): Got error 153 "No savepoint with that name" from storage engine InnoDB On optimized builds. On debug it crashes: 11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Debug) mariadbd: /test/11.0_dbg/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed. 11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Debug) Core was generated by `/test/MD180223-mariadb-11.0.1-linux-x86_64-dbg/bin/mariadbd --no-defaults --cor'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=22754753246784) at ./nptl/pthread_kill.c:44 [Current thread is 1 (Thread 0x14b200fbf640 (LWP 4047030))] (gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=22754753246784) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=22754753246784) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=22754753246784, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x000014b21a661476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x000014b21a6477f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x000014b21a64771b in __assert_fail_base (fmt=0x14b21a7fc150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55674898fd78 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x55674898fc58 "/test/11.0_dbg/sql/sql_error.cc", line=335, function=<optimized out>) at ./assert/assert.c:92 #6 0x000014b21a658e96 in __GI___assert_fail (assertion=0x55674898fd78 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x55674898fc58 "/test/11.0_dbg/sql/sql_error.cc", line=335, function=0x55674898fdb0 "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at ./assert/assert.c:101 #7 0x0000556747e41577 in Diagnostics_area::set_ok_status (this=0x14b1b4006b60, affected_rows=affected_rows@entry=0, last_insert_id=last_insert_id@entry=0, message=message@entry=0x0) at /test/11.0_dbg/sql/sql_error.cc:335 #8 0x0000556747e90191 in my_ok (message=0x0, id=0, affected_rows_arg=0, thd=0x14b1b4000d58) at /test/11.0_dbg/sql/sql_class.h:4426 #9 mysql_execute_command (thd=0x14b1b4000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/11.0_dbg/sql/sql_parse.cc:5713 #10 0x0000556747dc93c2 in sp_instr_stmt::exec_core (this=0x14b1b408c960, thd=<optimized out>, nextp=0x14b200fbd374) at /test/11.0_dbg/sql/sp_head.cc:3857 #11 0x0000556747dd65d4 in sp_lex_keeper::reset_lex_and_exec_core (this=this@entry=0x14b1b408c9a8, thd=thd@entry=0x14b1b4000d58, nextp=nextp@entry=0x14b200fbd374, open_tables=open_tables@entry=false, instr=instr@entry=0x14b1b408c960) at /test/11.0_dbg/sql/sp_head.cc:3582 #12 0x0000556747dd6d43 in sp_instr_stmt::execute (this=0x14b1b408c960, thd=0x14b1b4000d58, nextp=0x14b200fbd374) at /test/11.0_dbg/sql/sp_head.cc:3763 #13 0x0000556747dcf338 in sp_head::execute (this=this@entry=0x14b1b408b930, thd=thd@entry=0x14b1b4000d58, merge_da_on_success=merge_da_on_success@entry=true) at /test/11.0_dbg/sql/sp_head.cc:1459 #14 0x0000556747dd15da in sp_head::execute_procedure (this=0x14b1b408b930, thd=thd@entry=0x14b1b4000d58, args=0x14b1b4005ed8) at /test/11.0_dbg/sql/sp_head.cc:2446 #15 0x0000556747e7f473 in do_execute_sp (thd=thd@entry=0x14b1b4000d58, sp=sp@entry=0x14b1b408b930) at /test/11.0_dbg/sql/sql_parse.cc:3026 #16 0x0000556747e83c00 in Sql_cmd_call::execute (this=0x14b1b40131f0, thd=0x14b1b4000d58) at /test/11.0_dbg/sql/sql_parse.cc:3271 #17 0x0000556747e90db6 in mysql_execute_command (thd=thd@entry=0x14b1b4000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/11.0_dbg/sql/sql_parse.cc:6003 #18 0x0000556747e927cf in mysql_parse (thd=thd@entry=0x14b1b4000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14b200fbe2c0) at /test/11.0_dbg/sql/sql_parse.cc:8002 #19 0x0000556747e94963 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14b1b4000d58, packet=packet@entry=0x14b1b400ae19 "CALL p (@b)", packet_length=packet_length@entry=11, blocking=blocking@entry=true) at /test/11.0_dbg/sql/sql_class.h:242 #20 0x0000556747e967bc in do_command (thd=0x14b1b4000d58, blocking=blocking@entry=true) at /test/11.0_dbg/sql/sql_parse.cc:1407 #21 0x0000556747fe76e2 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55674aa26d58, put_in_cache=put_in_cache@entry=true) at /test/11.0_dbg/sql/sql_connect.cc:1416 #22 0x0000556747fe7941 in handle_one_connection (arg=0x55674aa26d58) at /test/11.0_dbg/sql/sql_connect.cc:1318 #23 0x000014b21a6b3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 #24 0x000014b21a745a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Confirmed the crash in 10.6-11.0 (dbg), and the error message in 10.6-11.0 (opt). 10.5 Does not look to be affected. If we remove TEMPORARY from the testcase for t2 , we get: 11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Debug) 11.0.1-dbg>INSERT INTO t2 VALUES(),(); ERROR 1180 (HY000): Got error 1 "Operation not permitted" during COMMIT 11.0.1-dbg>CALL p (@b); Query OK, 0 rows affected (0.000 sec) Any non-affected version will produce (with and without TEMPORARY ): 10.5.20 c41c79650aa2ef8eaf3f887b94db8cc7478eadd1 (Optimized) 10.5.20-opt>INSERT INTO t2 VALUES(),(); ERROR 1062 (23000): Duplicate entry '0' for key 'PRIMARY' 10.5.20-opt>CALL p (@b); Query OK, 0 rows affected (0.001 sec)
            Erland22 Erlandas added a comment -

            I am getting the error:

            `ERROR 1180 (HY000) at line 2245: Got error 1 "Operation not permitted" during COMMIT`

            on trying to import mysqldump into Mariadb 10.11.2

            the line 2245 has

            `INTO INTO plan_changes VALUES`

            and then values follow.

            The problem was caused by a duplicate entry (created on master running MariaDB 10.10.3). There is an index:

            Indexes
            PRIMARY id
            UNIQUE user_id, requirement_id

            and I found duplicate by running a query:

            ```
            SELECT user_id, requirement_id, COUNT cc
            FROM plan_changes
            GROUP BY user_id, requirement_id
            HAVING cc > 1

            ```

            Deleted one record on master, made dump again and I was able to import mysql dump on replica without issues.

            Normally, on duplicate I was getting error on other tables:

            ```
            Duplicate entry '9329-2023-02-01-0' for key 'listing_month'
            ```

            Duplicates somehow get created when a table has primary key + unique key and we perform 'on duplicate update' query. Not every time but about 100 duplicates found on a large table.

            Erland22 Erlandas added a comment - I am getting the error: `ERROR 1180 (HY000) at line 2245: Got error 1 "Operation not permitted" during COMMIT` on trying to import mysqldump into Mariadb 10.11.2 the line 2245 has `INTO INTO plan_changes VALUES` and then values follow. The problem was caused by a duplicate entry (created on master running MariaDB 10.10.3). There is an index: Indexes PRIMARY id UNIQUE user_id, requirement_id and I found duplicate by running a query: ``` SELECT user_id, requirement_id, COUNT cc FROM plan_changes GROUP BY user_id, requirement_id HAVING cc > 1 ``` Deleted one record on master, made dump again and I was able to import mysql dump on replica without issues. Normally, on duplicate I was getting error on other tables: ``` Duplicate entry '9329-2023-02-01-0' for key 'listing_month' ``` Duplicates somehow get created when a table has primary key + unique key and we perform 'on duplicate update' query. Not every time but about 100 duplicates found on a large table.

            Erland22 FYI, you can use {noformat}...{noformat} and {code:sql}...{code} tags in JIRA instead of ```.

            Roel Roel Van de Paar added a comment - Erland22 FYI, you can use {noformat}...{noformat} and {code:sql}...{code} tags in JIRA instead of ```.

            Thank you, the 10.6 version looks good to me. The 10.8 version is a bit different due to MDEV-24621. I still need to understand it better, but I do not expect any problems there.

            marko Marko Mäkelä added a comment - Thank you, the 10.6 version looks good to me. The 10.8 version is a bit different due to MDEV-24621 . I still need to understand it better, but I do not expect any problems there.

            The 10.8 version is different, because if there is an outstanding error noticed at the end of a statement or during the execution of XA PREPARE, we must retain the transaction as active for further error handling. We kind of roll it back while keeping the transaction active.

            marko Marko Mäkelä added a comment - The 10.8 version is different, because if there is an outstanding error noticed at the end of a statement or during the execution of XA PREPARE , we must retain the transaction as active for further error handling. We kind of roll it back while keeping the transaction active.

            People

              thiru Thirunarayanan Balathandayuthapani
              Roel Roel Van de Paar
              Votes:
              0 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.