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

innodb.deadlock_in_subqueries_join fails

    XMLWordPrintable

Details

    • Bug
    • Status: In Progress (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 11.0, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7
    • 10.6
    • Tests
    • None

    Description

      It fails with the following output:

      innodb.deadlock_in_subqueries_join 'innodb' w11 [ fail ]
              Test ended at 2024-03-28 16:40:42
      CURRENT_TEST: innodb.deadlock_in_subqueries_join
      Warning: /home/buildbot/amd64-debian-11-debug-ps-embedded/build/libmysqld/examples/mysqltest_embedded: unknown variable 'loose-ssl-ca=/home/buildbot/amd64-debian-11-debug-ps-embedded/build/mysql-test/std_data/cacert.pem'
      Warning: /home/buildbot/amd64-debian-11-debug-ps-embedded/build/libmysqld/examples/mysqltest_embedded: unknown variable 'loose-ssl-cert=/home/buildbot/amd64-debian-11-debug-ps-embedded/build/mysql-test/std_data/client-cert.pem'
      Warning: /home/buildbot/amd64-debian-11-debug-ps-embedded/build/libmysqld/examples/mysqltest_embedded: unknown variable 'loose-ssl-key=/home/buildbot/amd64-debian-11-debug-ps-embedded/build/mysql-test/std_data/client-key.pem'
      Warning: /home/buildbot/amd64-debian-11-debug-ps-embedded/build/libmysqld/examples/mysqltest_embedded: unknown option '--loose-skip-ssl'
      mysqltest: At line 72: query 'reap' succeeded - should have failed with error ER_LOCK_DEADLOCK (1213)...
      The result from queries just before the failure was:
      < snip >
      CREATE TABLE t3 (c int) engine = InnoDB;
      INSERT INTO t3 VALUES (10), (20), (30), (40), (50);
      connect con1, localhost,root,,;
      connection default;
      START TRANSACTION;
      UPDATE t3 SET c=c+1000;
      SELECT * FROM t1 FOR UPDATE;
      pkey	c
      1	1
      connection con1;
      START TRANSACTION;
      DELETE FROM t2 WHERE c NOT IN (SELECT ref_0.pkey FROM t1 AS ref_0 INNER JOIN t1 AS ref_1 ON ref_0.c = ref_0.pkey);
      connection default;
      SELECT * FROM t2 FOR UPDATE;
      pkey	c
      2	NULL
      COMMIT;
      connection con1;
      More results from queries before failure can be found in /home/buildbot/amd64-debian-11-debug-ps-embedded/build/mysql-test/var/11/log/deadlock_in_subqueries_join.log
       - saving '/home/buildbot/amd64-debian-11-debug-ps-embedded/build/mysql-test/var/11/log/innodb.deadlock_in_subqueries_join-innodb/' to '/home/buildbot/amd64-debian-11-debug-ps-embedded/build/mysql-test/var/log/innodb.deadlock_in_subqueries_join-innodb/'
      
      

      It looks like the following code is not strict enough for assuring that a statement is locked:

      let $wait_condition=
        SELECT count(*) = 1 FROM information_schema.processlist
        WHERE (state = 'Sending data' OR state = "Updating")
        AND (info LIKE 'delete from t2 where%' OR
             info LIKE 'UPDATE t2 SET pkey=pkey+10 WHERE%');
      --source include/wait_condition.inc
      

      Use debug syncpoints instead.

      Attachments

        Activity

          People

            vlad.lesin Vladislav Lesin
            vlad.lesin Vladislav Lesin
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.