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

Unexpected bypass of lock, Assertion `(have_max && !have_min) || (have_max && have_min && (max_res == 0))' failed in QUICK_GROUP_MIN_MAX_SELECT::get_next

    XMLWordPrintable

    Details

      Description

      On some reason I cannot get rid of concurrency between DELETE and INSERT in the test case. The test fails every time for me, which hints at some predictable execution of DELETE and INSERT, and yet I can't serialize them in any order. If I remove the concurrency, everything starts working as expected, SELECT .. FOR UPDATE ending with a timeout.

      --source include/have_innodb.inc
       
      CREATE TABLE t1 (pk INT, a INT, b INT, PRIMARY KEY (pk), KEY (a,b)) ENGINE=InnoDB;
      INSERT INTO t1 (pk,a) VALUES (1,11),(2,12),(3,13),(4,14);
       
      --connect (con1,localhost,root,,)
      --send
        DELETE FROM t1 WHERE pk <= 3;
       
      --connection default
      INSERT INTO t1 (pk) VALUES (5);
       
      --connection con1
      --reap
       
      START TRANSACTION;
      INSERT INTO t1 (pk) VALUES (6);
       
      --connection default
      SET lock_wait_timeout= 1, innodb_lock_wait_timeout= 1;
      --error ER_LOCK_WAIT_TIMEOUT
      SELECT MIN(b), MAX(b), a FROM t1 GROUP BY a FOR UPDATE;
       
      # Cleanup
      --connection con1
      COMMIT;
      DROP TABLE t1;
      --disconnect con1
      

      10.2 cd1a195b

      mysqld: /data/src/10.2/sql/opt_range.cc:14117: virtual int QUICK_GROUP_MIN_MAX_SELECT::get_next(): Assertion `(have_max && !have_min) || (have_max && have_min && (max_res == 0))' failed.
      210618 16:12:47 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007fd74b0ebf36 in __GI___assert_fail (assertion=0x5565c746b3e8 "(have_max && !have_min) || (have_max && have_min && (max_res == 0))", file=0x5565c74696f8 "/data/src/10.2/sql/opt_range.cc", line=14117, function=0x5565c746b3a0 "virtual int QUICK_GROUP_MIN_MAX_SELECT::get_next()") at assert.c:101
      #8  0x00005565c6ce247f in QUICK_GROUP_MIN_MAX_SELECT::get_next (this=0x7fd6f0182bf0) at /data/src/10.2/sql/opt_range.cc:14117
      #9  0x00005565c6cedd11 in rr_quick (info=0x7fd6f00150d0) at /data/src/10.2/sql/records.cc:373
      #10 0x00005565c6962ced in join_init_read_record (tab=0x7fd6f0015008) at /data/src/10.2/sql/sql_select.cc:19794
      #11 0x00005565c6960a2c in sub_select (join=0x7fd6f00136a0, join_tab=0x7fd6f0015008, end_of_records=false) at /data/src/10.2/sql/sql_select.cc:18865
      #12 0x00005565c695fff0 in do_select (join=0x7fd6f00136a0, procedure=0x0) at /data/src/10.2/sql/sql_select.cc:18412
      #13 0x00005565c6939c0d in JOIN::exec_inner (this=0x7fd6f00136a0) at /data/src/10.2/sql/sql_select.cc:3651
      #14 0x00005565c69390b4 in JOIN::exec (this=0x7fd6f00136a0) at /data/src/10.2/sql/sql_select.cc:3446
      #15 0x00005565c693a28e in mysql_select (thd=0x7fd6f0000d90, tables=0x7fd6f0012e30, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7fd6f0013570, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fd6f0013680, unit=0x7fd6f0004988, select_lex=0x7fd6f00050d8) at /data/src/10.2/sql/sql_select.cc:3849
      #16 0x00005565c692e3e2 in handle_select (thd=0x7fd6f0000d90, lex=0x7fd6f00048c8, result=0x7fd6f0013680, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:361
      #17 0x00005565c68f8ad6 in execute_sqlcom_select (thd=0x7fd6f0000d90, all_tables=0x7fd6f0012e30) at /data/src/10.2/sql/sql_parse.cc:6271
      #18 0x00005565c68ef64a in mysql_execute_command (thd=0x7fd6f0000d90) at /data/src/10.2/sql/sql_parse.cc:3582
      #19 0x00005565c68fc892 in mysql_parse (thd=0x7fd6f0000d90, rawbuf=0x7fd6f0012708 "SELECT MIN(b), MAX(b), a FROM t1 GROUP BY a FOR UPDATE", length=54, parser_state=0x7fd745407560, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7793
      #20 0x00005565c68eaaed in dispatch_command (command=COM_QUERY, thd=0x7fd6f0000d90, packet=0x7fd6f0008b61 "", packet_length=54, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1827
      #21 0x00005565c68e95e8 in do_command (thd=0x7fd6f0000d90) at /data/src/10.2/sql/sql_parse.cc:1381
      #22 0x00005565c6a44a6b in do_handle_one_connection (connect=0x5565c99a9a40) at /data/src/10.2/sql/sql_connect.cc:1336
      #23 0x00005565c6a447d0 in handle_one_connection (arg=0x5565c99a9a40) at /data/src/10.2/sql/sql_connect.cc:1241
      #24 0x00005565c7270bec in pfs_spawn_thread (arg=0x5565c9a4cc90) at /data/src/10.2/storage/perfschema/pfs.cc:1869
      #25 0x00007fd74b5fb609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #26 0x00007fd74b1d7293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Reproducible on 10.2-10.6 debug builds.

      Non-debug builds also behave in a strange way. SELECT .. FOR UPDATE stops waiting for a lock as it should, but after the timeout is exceeded, instead of failing it proceeds and returns a result.

      select now(6);
      now(6)
      2021-06-18 16:15:49.561749
      SELECT MIN(b), MAX(b), a FROM t1 GROUP BY a FOR UPDATE;
      MIN(b)	MAX(b)	a
      NULL	NULL	NULL
      NULL	NULL	14
      select now(6);
      now(6)
      2021-06-18 16:15:51.477560
      

        Attachments

          Activity

            People

            Assignee:
            wlad Vladislav Vaintroub
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:

                Git Integration