result error in hash partition table

[ChenPeng2013]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

use test;
drop table if exists pk_hp9278;
CREATE TABLE `PK_HP9278` (
  `COL1` bigint(45) unsigned NOT NULL DEFAULT '25' COMMENT 'NUMERIC PK',
  `COL2` varchar(20) DEFAULT NULL,
  `COL4` datetime DEFAULT NULL,
  `COL3` bigint(20) NOT NULL,
  `COL5` float DEFAULT NULL,
  PRIMARY KEY (`COL1`,`COL3`) /*T![clustered_index] NONCLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
PARTITION BY HASH( `COL1` )
PARTITIONS 4;
insert into pk_hp9278(col1, col3) values(13943595346712653009, -2477596606116969187);
SELECT count(T1.COL1) FROM PK_HP9278 AS T1 RIGHT JOIN PK_HP9278 AS T2 ON T1.COL1=T2.COL1 WHERE T1.COL1 BETWEEN 0 AND 15218001646226433652;

2. What did you expect to see? (Required)

mysql> SELECT count(T1.COL1) FROM PK_HP9278 AS T1 RIGHT JOIN PK_HP9278 AS T2 ON T1.COL1=T2.COL1 WHERE T1.COL1 BETWEEN 0 AND 15218001646226433652;
+----------------+
| count(T1.COL1) |
+----------------+
|              1 |
+----------------+
1 row in set (0.00 sec)

3. What did you see instead (Required)

release-5.1 and master

mysql> SELECT count(T1.COL1) FROM PK_HP9278 AS T1 RIGHT JOIN PK_HP9278 AS T2 ON T1.COL1=T2.COL1 WHERE T1.COL1 BETWEEN 0 AND 15218001646226433652;
+----------------+
| count(T1.COL1) |
+----------------+
|              0 |
+----------------+
1 row in set (0.01 sec)

4. What is your TiDB version? (Required)

Release Version: v5.1.0-64-gfb0eaf7b4
Edition: Community
Git Commit Hash: fb0eaf7b44b9ddb1494bf8194d8e361c538146dc
Git Branch: release-5.1
UTC Build Time: 2021-07-26 06:50:38
GoVersion: go1.16.5
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false

[guo-shaoge]

Looks like we didn't take care of unsigned int properly when pruning partition. Check (s *partitionProcessor) findUsedPartitions.

posHigh should be 15218001646226433652 instead of -3228742427483117964. Because it's an uint64 instead of int64. So the following computation of used partition is wrong.

[qw4990]

@tiancaiamao Could you take a look at this?

[ti-srebot]

Please edit this comment or add a new comment to complete the following information

Not a bug

1. Remove the 'type/bug' label
2. Add notes to indicate why it is not a bug

Duplicate bug

1. Add the 'type/duplicate' label
2. Add the link to the original bug

Bug

Note: Make Sure that 'component', and 'severity' labels are added
Example for how to fill out the template: #20100

1. Root Cause Analysis (RCA) (optional)

2. Symptom (optional)

3. All Trigger Conditions (optional)

4. Workaround (optional)

5. Affected versions

6. Fixed versions