-
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
planner: fix a bug when pushing streamAgg down (#41056) #41311
planner: fix a bug when pushing streamAgg down (#41056) #41311
Conversation
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
[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. |
@Dousir9 There is merge conflict, can you resolve the conflict? thanks. |
Sure. |
/cherry-pick-invite |
@Dousir9 you're not a member of org |
/cherry-pick-invite |
@hawkingrei Please accept the invitation then you can push to the cherry-pick pull requests. |
Signed-off-by: Weizhen Wang <wangweizhen@pingcap.com>
/retest |
Thanks for @hawkingrei . |
/cc fixdb |
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.
+1
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fixdb, hawkingrei, YangKeao The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
This is an automated cherry-pick of #41056
What problem does this PR solve?
Issue Number: close #40857
Problem Summary:
minimal reproduce process:
The following plan will introduce this panic:
What happend:
In indexLookUp, the
handles
(row id) fetched from index is originally ordered by index, whenkeepOrder
is true, we will save the order ofhandles
inindexOrder
, and thentableWorker
will usehandles
to rescan table to obtain rows. IfkeepOrder
is true, thetableWorker
will restore the rows to the original order throughindexOrder
. When restoring, we need to extract thehandle
from the row. In the above plan, theagg
is pushed down, and its schma only containsc6
and does not contain thehandle
, but the executor thinks that thehandle
is in the third column of the row, resulting in "index out of range [2]".What is changed and how it works?
The reason for the above error is that streamAgg was pushed down to double read when
keepOrder
was true. I looked through the historical PRs and found that @winoros solved this problem in PR#12443: if the original order of index needs to be maintained during double read (Call this situation doubleReadWithOrderReserved), we will prevent the optimizer from pushing streamagg down to double read. PR#12443 usesextraHandleCol
to determine whether the current situation is doubleReadWithOrderReserved. At that time, ifextraHandleCol != nil
, then it must be the case of doubleReadWithOrderReserved.But then PR#18054 added
!ds.tableInfo.IsCommonHandle
, which causedextraHandleCol
may benil
in the case of doubleReadWithOrderReserved, so we can’t useextraHandleCol
, we can use(cop.indexPlan != nil && cop.tablePlan != nil && cop.keepOrder)
to represent this situation .Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.