Regression: descending primary-key range scan on a partitioned InnoDB table fails with ERROR 1032

A descending primary-key range query against a RANGE-partitioned InnoDB table fails with:

1

ERROR 1032 (HY000): Can't find record in 'ints'

The minimal reproduction requires only one integer primary key, three partitions, and three rows. It reproduces directly through the mariadb command-line client, without an application or JDBC driver.

The same reproduction fails on MariaDB 12.3.3 and 13.0.2 but returns the correct result on 11.8.9.

There are no concurrent writes, partition alterations, generated columns, UUID columns, or secondary indexes involved.

Steps to reproduce

Run the following in an empty test database:

1

SELECT VERSION();

2

3

CREATE TABLE ints (

4

    id INT NOT NULL PRIMARY KEY

5

) ENGINE=InnoDB

6

PARTITION BY RANGE(id) (

7

    PARTITION p0 VALUES LESS THAN (100),

8

    PARTITION p1 VALUES LESS THAN (200),

9

    PARTITION p2 VALUES LESS THAN (300)

10

);

11

12

INSERT INTO ints VALUES (101), (102), (103);

13

14

SELECT *

15

FROM ints

16

WHERE id >= 0 AND id < 103

17

ORDER BY id DESC

18

LIMIT 512;

Expected result

1

+-----+

2

| id  |

3

+-----+

4

| 102 |

5

| 101 |

6

+-----+

Actual result

1

ERROR 1032 (HY000): Can't find record in 'ints'

Tested versions

Tests were performed using official MariaDB Docker images, in separate disposable containers.

Other versions have not been tested. The exact first affected version has not been established.

Additional observations

On 13.0.2, the following variations succeed:

1

-- Stop after retrieving the two qualifying rows.

2

SELECT *

3

FROM ints

4

WHERE id >= 0 AND id < 103

5

ORDER BY id DESC

6

LIMIT 2;

7

8

-- Scan in ascending order.

9

SELECT *

10

FROM ints

11

WHERE id >= 0 AND id < 103

12

ORDER BY id ASC

13

LIMIT 512;

14

15

-- Restrict the range to one partition.

16

SELECT *

17

FROM ints

18

WHERE id >= 100 AND id < 103

19

ORDER BY id DESC

20

LIMIT 512;

21

22

-- Change the ordering expression.

23

SELECT *

24

FROM ints

25

WHERE id >= 0 AND id < 103

26

ORDER BY (id + 0) DESC

27

LIMIT 512;

Changing the failing query's upper bound from id < 103 to id < 104 still produces ERROR 1032.

For the original failing query, EXPLAIN PARTITIONS on 13.0.2 reports:

1

partitions: p0,p1

2

type:       range

3

key:        PRIMARY

4

key_len:    4

5

rows:       3

6

Extra:      Using where

These observations suggest a problem when exhausting a descending range scan across partitions. This is an inference from the query variations, not a confirmed diagnosis of the server internals.

Possibly related issue

MDEV-40479 concerns incorrect results during descending scans over partitioned tables.

However, PR #5708 changes a prefix comparison from key number 0 to active_index, addressing a secondary-index case. This reproduction uses only the primary key, where the active index is already 0.

I have not tested a build containing that patch, so I cannot confirm whether this is a separate defect or another manifestation of the same underlying problem.

Impact

Valid descending range queries fail, affecting historical-data retrieval and cursor-based pagination over partitioned tables. Application-side workarounds require changing the execution path or querying individual partition ranges.