Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The execution result of using TableDual plan is not correct #23846

Closed
lilinghai opened this issue Apr 5, 2021 · 4 comments · Fixed by #23860
Closed

The execution result of using TableDual plan is not correct #23846

lilinghai opened this issue Apr 5, 2021 · 4 comments · Fixed by #23860
Assignees
Labels
severity/critical sig/planner SIG: Planner type/bug The issue is confirmed as a bug.

Comments

@lilinghai
Copy link
Contributor

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

create table t(a varbinary(10),UNIQUE KEY(a));
insert into t values(0x00A4EEF4FA55D6706ED5);
select count(*) from t where a=0x00A4EEF4FA55D6706ED5; -- 1
desc select * from t where a=0x00A4EEF4FA55D6706ED5; -- TableDual_2 plan
select * from t where a=0x00A4EEF4FA55D6706ED5; -- Empty result

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

0x00A4EEF4FA55D6706ED5

3. What did you see instead (Required)

Empty result

4. What is your TiDB version? (Required)

Release Version: v4.0.0-beta.2-2561-g9c75cfa4e
Edition: Community
Git Commit Hash: 9c75cfa
Git Branch: master
UTC Build Time: 2021-04-05 07:39:46
GoVersion: go1.15.1
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false

@lilinghai lilinghai added the type/bug The issue is confirmed as a bug. label Apr 5, 2021
@dveeden
Copy link
Contributor

dveeden commented Apr 5, 2021

I failed to reproduce this on TiDB 5.0

Query OK, 0 rows affected (0.13 sec)

mysql 5.7.25-TiDB-v5.0.0-nightly > insert into t values(0x00A4EEF4FA55D6706ED5);
Query OK, 1 row affected (0.02 sec)

mysql 5.7.25-TiDB-v5.0.0-nightly > select count(*) from t where a=0x00A4EEF4FA55D6706ED5;
+----------+
| count(*) |
+----------+
|        1 |
+----------+
1 row in set (0.01 sec)

mysql 5.7.25-TiDB-v5.0.0-nightly > desc select * from t where a=0x00A4EEF4FA55D6706ED5;
+-------------+---------+------+---------------------+---------------+
| id          | estRows | task | access object       | operator info |
+-------------+---------+------+---------------------+---------------+
| Point_Get_1 | 1.00    | root | table:t, index:a(a) |               |
+-------------+---------+------+---------------------+---------------+
1 row in set (0.00 sec)

mysql 5.7.25-TiDB-v5.0.0-nightly > select * from t where a=0x00A4EEF4FA55D6706ED5;
+------------------------+
| a                      |
+------------------------+
| 0x00A4EEF4FA55D6706ED5 |
+------------------------+
1 row in set (0.00 sec)

mysql 5.7.25-TiDB-v5.0.0-nightly > SELECT tidb_version()\G
*************************** 1. row ***************************
tidb_version(): Release Version: v5.0.0-nightly
Edition: Community
Git Commit Hash: e2740f54b6b29d99f3396bed4e66779549becf75
Git Branch: heads/refs/tags/v5.0.0-nightly
UTC Build Time: 2021-04-02 16:25:23
GoVersion: go1.13
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false
1 row in set (0.00 sec)

@lilinghai
Copy link
Contributor Author

lilinghai commented Apr 5, 2021

@dveeden I found the issue in the master branch. The execution result of PointGet plan is correct in the 5.0 nightly.

@qw4990 qw4990 self-assigned this Apr 6, 2021
@qw4990
Copy link
Contributor

qw4990 commented Apr 6, 2021

I find this issue is caused by #23523 which is supposed to fix another bug.
I'll fix this issue soon.

@ti-srebot
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/critical sig/planner SIG: Planner type/bug The issue is confirmed as a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants