-
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
table/tables: fix buildListColumnsPruner issue in the list partition (#32621) #32772
Conversation
Signed-off-by: ti-srebot <[email protected]>
[REVIEW NOTIFICATION] This pull request has not been approved. 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 |
@ti-srebot: This cherry pick PR is for a release branch and has not yet been approved by release team. To merge this cherry pick, it must first be approved by the collaborators. AFTER it has been approved by collaborators, please ping the release team in a comment to request a cherry pick review. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@zimulala you're already a collaborator in bot's repo. |
List partitions are experimental and this issue is not critical, so don't cherry pick |
cherry-pick #32621 to release-5.4
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/32772
After apply modifications, you can push your change to this PR via:
What problem does this PR solve?
Issue Number: close #32416
Problem Summary:
This also affects the master. This problem can also occur in the following scenario:
The above scenario is analyzed in detail:
In step 1
In the bootstrap phase, new collation is true
After bootstrap ends, new collation is false.
In step 2
EncodeKey
) in TableFromMetaEncodeKey
) could not be found in the hashMap.What is changed and how it works?
Instead of creating the hashMap in the
TableFromMeta
phase( In the bootstrap phase), we create the hashMap on a delayed basis (that is, when a partition needs to be located).In this way,
new_collations_enabled_on_first_bootstrap
does not have inconsistency problems.Check List
Tests
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:The above scenario is analyzed in detail:
Side effects
Documentation
Release note