-
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
*: query failed after add index / timestamp out-of-range (#28424) (#29323) #30985
Conversation
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
[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. |
@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. |
/run-all-tests |
@mjonss you're already a collaborator in bot's repo. |
This pull request is closed because it's related version has closed automatic cherry-picking. You can find more details at: |
cherry-pick #29323 to release-5.2
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/30985
After apply modifications, you can push your change to this PR via:
What problem does this PR solve?
Issue Number: close #28424
Problem Summary: Timestamp out-of-range and range optimizer incompatibility.
What is changed and how it works?
Two issues, convertToMysqlTimestamp did set out-of-range timestamp to
Zero, when it would still be a storable/comparable KindMysqlTime.
(we only artificially limit the range of Timestamp to be compatible
with MySQL).
When this change was done,
it broke #26584 (insert of invalid timestamp succeeded),
which needed a different change in handleZeroDatetime
Check List
Tests
Side effects
Documentation
Release note