-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
ddl: fix concurrent column type changes(with changing data) that cause schema and data inconsistencies #31051
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/12962ce7f6a4125778c3bde248f967318a5e2726 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -1062,6 +1062,54 @@ func (s *testStateChangeSuite) TestParallelAlterModifyColumn(c *C) { | |||
s.testControlParallelExecSQL(c, sql, sql, f) | |||
} | |||
|
|||
func (s *testStateChangeSuite) TestParallelAlterModifyColumnWithData(c *C) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add more tests about concurrent alter table
? For example, random test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you give an example of this random test? I don't think it's appropriate to add it here.
6abc8ef
to
7f98a78
Compare
PTAL @wjhuang2016 @bb7133 |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 7f98a78
|
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
cherry pick to release-5.1 in PR #31069 |
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
cherry pick to release-5.2 in PR #31070 |
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
cherry pick to release-5.3 in PR #31071 |
What problem does this PR solve?
Issue Number: close #31048
Problem Summary:
For column type changes, the column ID is changed if it is lossy.
If both sessions perform lossy column type changes((like modify column c int -> char)) simultaneously
Connection1: execute DDL1, it will change column ID (ID :1-> ID :2)
Connection2: execute DDL2. After DDL1 enters the DDL job queue and is not executed, then DDL2 enters the job queue.
After DDL1 is executed successfully, DDL2 considers that the column is not lossy(char -> char), so it does not change the column ID, which is the old id:1. So id:1 overwrites id:2.
After DDL2 is completed, the column ID is still the original id:1 instead of the correct id:2.
Because the column ID was changed incorrectly, the schema could not match the data, resulting in decode failure when reading data.
What is changed and how it works?
In step 3, we check that the ID of the modified column is the same as the ID of the original column.
Check List
Tests
Side effects
Documentation
Release note