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

Join with a RANGE partitioned table never finishes when the join keys skip a partition, and KILL does not stop it

    XMLWordPrintable

Details

    Description

      --source include/have_partition.inc
      --source include/have_sequence.inc
       
      CREATE TABLE t1 (x INT, y INT);
      INSERT INTO t1 VALUES (5,25);
      CREATE TABLE t2 (a INT, b INT, KEY(a)) PARTITION BY RANGE (a) (PARTITION p0 VALUES LESS THAN (10), PARTITION p1 VALUES LESS THAN (20), PARTITION p2 VALUES LESS THAN MAXVALUE);
      INSERT INTO t2 SELECT seq, seq FROM seq_1_to_3000;
      ANALYZE TABLE t1, t2 PERSISTENT FOR ALL;
      --connect (con1,localhost,root,,test)
      --send SELECT t2.a FROM t1, t2 WHERE t2.a = t1.x OR t2.a = t1.y
      --connection default
      --sleep 5
      --let $c= query_get_value(SELECT COUNT(*) AS c FROM information_schema.PROCESSLIST WHERE INFO LIKE 'SELECT t2.a FROM t1%', c, 1)
      if ($c)
      {
        --die The join never finishes: the range scan on t2 loops on partition p1, which has no range to read
      }
      --connection con1
      --reap
      --disconnect con1
      --connection default
      DROP TABLE t1, t2;

      Leads to:

      CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 06/10/2026

      mysqltest: At line 16: The join never finishes: the range scan on t2 loops on partition p1, which has no range to read

      The join runs at 100% CPU, and KILL leaves it in state Killed, still running. Debug builds hang in the same way. So does the same join on InnoDB, where the plan is "Range checked for each record", and a BKA join (join_cache_level=6, mrr=on) whose outer keys map to p0 and p2 only. CS 11.8.9 returns the rows 5 and 25.

      From the code it seems that ha_partition::multi_range_read_init() marks in m_mrr_used_partitions only the partitions that an exact range maps to. Pruning cannot use t1.x and t1.y, so p1 stays in read_partitions without a range. ha_partition::handle_unordered_scan_next_partition() skips such a partition with continue, but its loop moves to the next partition only at the end of the loop body, so the scan stays on p1.

      Attachments

        Issue Links

          Activity

            People

              ycp Yuchen Pei
              Roel Roel Van de Paar
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - Not Specified
                  Not Specified
                  Logged:
                  Time Spent - 1h
                  1h

                  Git Integration

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