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

union scan result error when using dynamic mode #26719

Closed
ChenPeng2013 opened this issue Jul 29, 2021 · 4 comments · Fixed by #26755 or #26876
Closed

union scan result error when using dynamic mode #26719

ChenPeng2013 opened this issue Jul 29, 2021 · 4 comments · Fixed by #26755 or #26876
Assignees
Labels
severity/critical sig/planner SIG: Planner type/bug The issue is confirmed as a bug.

Comments

@ChenPeng2013
Copy link
Contributor

ChenPeng2013 commented Jul 29, 2021

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

use test;
drop table if exists t;
set tidb_partition_prune_mode=dynamic;

CREATE TABLE t( id INT NOT NULL, store_id INT NOT NULL) PARTITION BY RANGE (store_id) ( 
  PARTITION p0 VALUES LESS THAN (6), 
  PARTITION p1 VALUES LESS THAN (11), 
  PARTITION p2 VALUES LESS THAN (16));

insert into t values(1,1), (5,5);
insert into t values(-1,-10), (10,10), (11, 12);
begin;
delete from t where id in(1);
insert into t values(1, 1);
delete from t where id in(1);
select * from t PARTITION(p0) order by id;
commit;

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

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> delete from t where id in(1);
Query OK, 1 row affected (0.00 sec)

mysql> insert into t values(1, 1);
Query OK, 1 row affected (0.00 sec)

mysql> delete from t where id in(1);
Query OK, 2 rows affected (0.00 sec)

mysql> select * from t PARTITION(p0) order by id;
+----+----------+
| id | store_id |
+----+----------+
| -1 |      -10 |
|  5 |        5 |
+----+----------+
2 rows in set (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

3. What did you see instead (Required)

release-5.0 & release-5.1 & master

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> delete from t where id in(1);
Query OK, 1 row affected (0.00 sec)

mysql> insert into t values(1, 1);
Query OK, 1 row affected (0.00 sec)

mysql> delete from t where id in(1);
Query OK, 2 rows affected (0.00 sec)

mysql> select * from t PARTITION(p0) order by id;
+----+----------+
| id | store_id |
+----+----------+
| -1 |      -10 |
|  1 |        1 |
|  5 |        5 |
+----+----------+
3 rows in set (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

4. What is your TiDB version? (Required)

Release Version: v5.1.0-66-g797bddd25
Edition: Community
Git Commit Hash: 797bddd25310ed42f0791c8eccb78be8cce2f502
Git Branch: release-5.1
UTC Build Time: 2021-07-29 03:28:11
GoVersion: go1.16.5
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false
@ChenPeng2013 ChenPeng2013 added type/bug The issue is confirmed as a bug. sig/planner SIG: Planner severity/major labels Jul 29, 2021
@ChenPeng2013
Copy link
Contributor Author

Dynamic Pruning Mode for Partitioned Tables is experimental feature

@qw4990 qw4990 self-assigned this Jul 29, 2021
@qw4990
Copy link
Contributor

qw4990 commented Jul 30, 2021

A minimal reproducible case:

create table tx (a int) partition by range (a) (partition p0 values less than (10), partition p1 values less than (20));
insert into tx values (1);

set tidb_partition_prune_mode=dynamic;
begin;
delete from tx where a in (1);
select * from tx PARTITION(p0);
rollback;

@qw4990
Copy link
Contributor

qw4990 commented Jul 30, 2021

Root Cause:

  1. When processing a selection in a transaction, UnionScan encodes rows into keys and looks up them in its buffer to check if these rows have been deleted(see here);
  2. When encoding these rows, their partition table IDs are needed, but in dynamic-mode, UnionScan cannot know the actual partition table IDs of these rows now;

Related Problem: Select for Update has the same problem, and it is fixed by #21148;

Solution: Fixing it thoroughly is a little complicated and has more risks, so now we decided to just quick fix it by disabling dynamic-mode in transactions, and fix it thoroughly next Sprint.

@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
3 participants