[ES-2763] [COR-51] Fix crash on nested subqueries with modification #22157
+283
−188
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
markuspf
force-pushed
the
bug-fix/es-2763-nested-subquery-modification
branch
2 times, most recently
from
5bf37dc to
8867a41
Compare
markuspf
changed the title
markuspf
force-pushed
the
bug-fix/es-2763-nested-subquery-modification
branch
3 times, most recently
from
643965f to
b1d4825
Compare
markuspf
force-pushed
the
bug-fix/es-2763-nested-subquery-modification
branch
from
6feba92 to
5100f56
Compare
mpoeter
reviewed
Dec 19, 2025
Comment on lines
+1398
to
+1405
| // TODO: the original sideEffectShadowRowForwarding returns | ||
| // ExecState::DONE in this case. It is likely correct | ||
| // to just return ExecState::NEXTSUBQUERY and remove this | ||
| // case distinction. | ||
| // Let's do that in a separate PR. In particular keep UPSERT in mind. | ||
| if constexpr (executorHasSideEffects<Executor>) { | ||
| return ExecState::DONE; | ||
| } else { |
Contributor
There was a problem hiding this comment.
If we want to address this in a follow-up PR I suggest we create a ticket and reference it here.
| return shadowRowForwardingSubqueryStart(stack); | ||
| } else if constexpr (std::is_same_v<Executor, SubqueryEndExecutor>) { | ||
| return shadowRowForwardingSubqueryEnd(stack); | ||
| } else { |
Contributor
There was a problem hiding this comment.
I think we should leave this else here in place.
Contributor
Author
There was a problem hiding this comment.
I am not sure I understand; you mean wrap the whole rest of the function into the {} after the else?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Scope & Purpose
Customer reported problems when executing a complex query that involved modification operations inside nested subqueries.
The added regression test shows that the problem occurs when a modification executor is nested within 3 subqueries.
During AQL execution, modification executors are special: they always request to see all their inputs, even if a subsequent
LIMITwould otherwise mean that rows aren't fetched.At some point during execution, it can happen that a subquery call on the modification executors' callstack is empty.
Execution then runs into an assertion on current
devel, because the check whether the modification executor needs to be handled specially duringsideEffectShadowRowForwardingtries to peek the next call of the call stack at every level (inneedToCountSubquery).This solution merges
shadowRowForwardingandsideEffectShadowRowForwardinginto one function that handles the side effect case inline; I hope that makes it slightly more transparent.When the callstack contains an empty call, the executor cannot know what to do, so it is not allowed to do anything and just returns
ExecState::DONEnow.Checklist