-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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) #31069
ddl: fix concurrent column type changes(with changing data) that cause schema and data inconsistencies (#31051) #31069
Conversation
Signed-off-by: ti-srebot <[email protected]>
[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. |
/run-all-tests |
@zimulala please accept the invitation then you can push to the cherry-pick pull requests. Comment with |
/run-mysql-test |
1 similar comment
/run-mysql-test |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: e2666b3
|
cherry-pick #31051 to release-5.1
You can switch your code base to this Pull Request by using git-extras:
# In tidb repo: git pr https://github.com/pingcap/tidb/pull/31069
After apply modifications, you can push your change to this PR via:
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