-
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
session, table: fix listColumnPartition data race #33199
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/42f067fb0572e433c18214768986639400fbc2d0 |
/run-unit-test |
/run-unit-test |
1 similar comment
/run-unit-test |
PTAL @wjhuang2016 |
/hold |
/unhold |
/hold |
continue | ||
} | ||
|
||
pe, err := t.(partitionExpr).PartitionExpr() |
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.
I don't think it's a good style, IMO a better way to do it is something like:
pt := t.(table.PartitionedTable); err != nil {
panic(...)
}
pe, err := t.PartitionExpr()
Which is more clear. However, some extra changes are required and it might not be a good idea to make it in this PR.
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.
However, it is already confirmed that it is a partitioned table, so theoretically this(t.(partitionExpr)
) should not report an error.
PTAL @bb7133 |
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
/merge |
/merge |
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
cherry pick to release-6.0 in PR #34285 |
TiDB MergeCI notify✅ Well Done! New fixed [1] after this pr merged.
|
What problem does this PR solve?
Issue Number: close #33030
Problem Summary:
ForListColumnPruning
has a lot of fields, if we use the lock to fix data race, it will make the code dirty.So I change the way to fix #32416.
#32416 :
In step 1
In the bootstrap phase, new collation is true
After bootstrap ends, new collation is false.
In step 2
a. In the bootstrap phase, new collation is true. ForListColumnPruning builds the hashMap(generate the partition hash key, by calling
EncodeKey
) in TableFromMetab. After bootstrap ends, new collation is false. The generated partition hash key(by calling
EncodeKey
) could not be found in the hashMap.What is changed and how it works?
This way I will rebuild hashMap with
new collation is false
after step 2.a. Then we can find the key in step 2.b.Check List
Tests
Unit test
Tests already exist: TestLocatePartition
Integration test
Manual test (add detailed scripts or steps below)
new_collations_enabled_on_first_bootstrap
item to false and run the SQL statements as follows:new_collations_enabled_on_first_bootstrap = false
and execute the following statements:Side effects
Documentation
Release note