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

ER_KEY_NOT_FOUND or Assertion `0' failed in Protocol::end_statement upon ALTER on sequence

    XMLWordPrintable

    Details

      Description

      CREATE SEQUENCE s;
      LOCK TABLE s WRITE;
      ALTER IGNORE TABLE s ADD CHECK (maximum_value < 1000000);
       
      # Cleanup
      DROP SEQUENCE s;
      

      ALTER above causes ER_KEY_NOT_FOUND on release and debug builds:

      10.3 38d62189

      mysqltest: At line 5: query 'ALTER IGNORE TABLE s ADD CHECK (maximum_value < 1000000)' failed: 1032: Can't find record in 's'
      

      It is also written into the error log.
      It is quite bad, because ER_KEY_NOT_FOUND normally indicates data corruption and thus would alarm users.
      Reproducible on 10.3-10.5.

      If we add binary logging to the scenario, we also get a debug assertion failure:

      --source include/have_log_bin.inc
       
      CREATE SEQUENCE s;
      LOCK TABLE s WRITE;
      ALTER IGNORE TABLE s ADD CHECK (maximum_value < 1000000);
       
      # Cleanup
      DROP SEQUENCE s;
      

      mysqld: /data/src/10.3/sql/protocol.cc:599: void Protocol::end_statement(): Assertion `0' failed.
      200517  2:28:49 [ERROR] mysqld got signal 6 ;
       
      #6  0x00007f028040de67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x565278f72858 "0", file=file@entry=0x565278f72538 "/data/src/10.3/sql/protocol.cc", line=line@entry=599, function=function@entry=0x565278f731d0 <Protocol::end_statement()::__PRETTY_FUNCTION__> "void Protocol::end_statement()") at assert.c:92
      #7  0x00007f028040df12 in __GI___assert_fail (assertion=0x565278f72858 "0", file=0x565278f72538 "/data/src/10.3/sql/protocol.cc", line=599, function=0x565278f731d0 <Protocol::end_statement()::__PRETTY_FUNCTION__> "void Protocol::end_statement()") at assert.c:101
      #8  0x000056527822417a in Protocol::end_statement (this=0x7f025c0010a8) at /data/src/10.3/sql/protocol.cc:599
      #9  0x0000565278337189 in dispatch_command (command=COM_QUERY, thd=0x7f025c000af0, packet=0x7f025c1233b1 "", packet_length=56, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:2412
      #10 0x0000565278333d67 in do_command (thd=0x7f025c000af0) at /data/src/10.3/sql/sql_parse.cc:1401
      #11 0x00005652784ac017 in do_handle_one_connection (connect=0x56527c53c880) at /data/src/10.3/sql/sql_connect.cc:1403
      #12 0x00005652784abd79 in handle_one_connection (arg=0x56527c53c880) at /data/src/10.3/sql/sql_connect.cc:1308
      #13 0x0000565278e6070c in pfs_spawn_thread (arg=0x56527c4a1150) at /data/src/10.3/storage/perfschema/pfs.cc:1869
      #14 0x00007f02823964a4 in start_thread (arg=0x7f027a5c2700) at pthread_create.c:456
      #15 0x00007f02804cad0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      Reproducible on 10.3-10.4, not on the current 10.5.

      However, I find ER_KEY_NOT_FOUND to be a more serious problem here than the assertion failure.

        Attachments

          Activity

            People

            Assignee:
            sanja Oleksandr Byelkin
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: