-
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
executor: change the evaluation order of columns in Update
and Insert
statements (#57123)
#58524
base: release-7.1
Are you sure you want to change the base?
executor: change the evaluation order of columns in Update
and Insert
statements (#57123)
#58524
Conversation
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
This cherry pick PR is for a release branch and has not yet been approved by triage owners. To merge this cherry pick:
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-sigs/prow repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/ok-to-test |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release-7.1 #58524 +/- ##
================================================
Coverage ? 73.4723%
================================================
Files ? 1213
Lines ? 382190
Branches ? 0
================================================
Hits ? 280804
Misses ? 83448
Partials ? 17938 |
This is an automated cherry-pick of #57123
What problem does this PR solve?
Issue Number: ref #56829
Problem Summary:
In the previous logic, when we use
UPDATE
orINSERT ON DUPLICATE
, the new row will be generated in the following order:UPDATE
andINSERT
, they are evaluated incomposeGeneratedColumns
anddoDupRowUpdate
respectively.However, auto-generated columns may rely on the on-update-now columns to generate value. For example in #56829 (comment)
expired_at
is generated based on the latest timestamp value fromupdated_at
. So we will get wrongexpired_at
value. Even worse,expired_at
is the part of the indexidx_c_on_expired_at
. So querying dataexpired_at
using index scan and full table scan will get different result, since in full table scan,expired_at
is calculated in real-time.This also explains #56829 (comment) why changing
VIRTUAL
toSTORED
will not yield such error, although this value itself is incorrect.What changed and how does it work?
To address this problem, this PR refactor the logic of
INSERT ON DUPLICATE
andUPDATE
. More specifically:updateRecord
.updateRecord
.errorHandler
function forUPDATE
andINSERT
to handle error/warning inupdateRecord
.Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.