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

A row got updated twice by one update statement #19585

Closed
zyguan opened this issue Aug 28, 2020 · 5 comments
Closed

A row got updated twice by one update statement #19585

zyguan opened this issue Aug 28, 2020 · 5 comments
Assignees

Comments

@zyguan
Copy link
Contributor

zyguan commented Aug 28, 2020

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

drop table if exists t1;
create table t1  (c_int int, primary key (c_int)) partition by range (c_int) (partition p0 values less than (10), partition p1 values less than maxvalue) ;
insert into t1 (c_int) values (1);

begin;
insert into t1 values (10);
update t1 set c_int = c_int + 10 where c_int in (1, 11);
commit;
select * from t1 order by c_int;

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

+-------+
| c_int |
+-------+
|    10 |
|    11 |
+-------+

3. What did you see instead (Required)

+-------+
| c_int |
+-------+
|    10 |
|    21 |
+-------+

4. What is your TiDB version? (Required)

master @ b0c3fe7

@zyguan zyguan added the type/bug The issue is confirmed as a bug. label Aug 28, 2020
@zyguan
Copy link
Contributor Author

zyguan commented Aug 28, 2020

/assign @tiancaiamao

@tiancaiamao
Copy link
Contributor

If nobody tells me about this issue, I would never know it ever happened.

After a binary search between different commits, I locate the bug.
It is introduced in this commit, refactoring the code to use the new partition implementation:

#18981

And the bug is fixed by another refactoring, remove DirtyDB and DirtyTable:

#19042

The bug is introduced partly due to the complex design of DirtyTable, the partition table did not consider all the corner cases.
And the bug is also fixed by a refactoring of removing DirtyTable, thus remove the design complexity.

This story is a perfect example of "Complexity is the enemy of software engineering".
And keeping a simple design help reducing the change of bugs.

@tiancaiamao
Copy link
Contributor

tiancaiamao commented Sep 18, 2020

Both commits are on the master branch
3.x 4.x release branch is not affected.

@sre-bot
Copy link
Contributor

sre-bot commented Sep 21, 2020

Integrity check:
component RCA symptom trigger_condition wa affect_version fix_version fields are empty
@tiancaiamao
Please comment /info to get template

@ti-srebot
Copy link
Contributor

ti-srebot commented Sep 21, 2020

Please edit this 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

1. Root Cause Analysis (RCA)

During partition table refactoring, some corner case in union scan is not considered.

2. Symptom

Not in any TiDB released version

3. All Trigger Conditions

See Minimal reproduce step

4. Workaround (optional)

5. Affected versions

unreleased

6. Fixed versions

unplanned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants