[BugFix] Fix the has_output check bug of scan operator (backport #42994) #43006
Conversation
This file contains 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
![mergify[bot]](https://avatars.githubusercontent.com/in/10562?s=60&v=4){kind=small}
Signed-off-by: trueeyu <[email protected]> (cherry picked from commit d9d9c70) # Conflicts: # be/src/exec/pipeline/scan/olap_scan_prepare_operator.cpp # be/src/testutil/sync_point.h # be/test/CMakeLists.txt
|
Cherry-pick of d9d9c70 has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
23 tasks
|
@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr |
Signed-off-by: trueeyu <[email protected]>
Signed-off-by: trueeyu <[email protected]>
Signed-off-by: trueeyu <[email protected]>
Signed-off-by: trueeyu <[email protected]>
Signed-off-by: trueeyu <[email protected]>
Signed-off-by: trueeyu <[email protected]>
Signed-off-by: trueeyu <[email protected]>
trueeyu
approved these changes
Mar 25, 2024
trueeyu
added a commit
to trueeyu/starrocks
that referenced
this pull request
Mar 26, 2024
…Rocks#42994) (StarRocks#43006) Signed-off-by: trueeyu <[email protected]> Co-authored-by: trueeyu <[email protected]>
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.
Why I'm doing:
What we expect is that
ScanOperator::pull_chunkcan be executed only afterScanPrepareOperator::pull_chunkis executed finished and return success.If
ScanPrepareOperator::pull_chunkreturns EOF,ScanOperator::pull_chunkshould not be executed.But when in function
OlapScanPrepareOperator::pull_chunk, if_ctx->set_prepare_finishedis executed finished and before _ctx->set_finished() is executed,will return true, causing
OlapScanOperator::pull_chunkwill be executed, causing some unexpected crashes.There are dependencies between operators. The current scheduling does not consider this dependency, which is not a good design.
But the current fix does not change the implementation of this pipeline engine.
What I'm doing:
If prepare return eof, we will first
set_finishedand thenset_prepare_finished.What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check:
This is an automatic backport of pull request #42994 done by [Mergify](https://mergify.com). ## Why I'm doing:
What we expect is that
ScanOperator::pull_chunkcan be executed only afterScanPrepareOperator::pull_chunkis executed finished and return success.If
ScanPrepareOperator::pull_chunkreturns EOF,ScanOperator::pull_chunkshould not be executed.But when in function
OlapScanPrepareOperator::pull_chunk, if_ctx->set_prepare_finishedis executed finished and before _ctx->set_finished() is executed,will return true, causing
OlapScanOperator::pull_chunkwill be executed, causing some unexpected crashes.There are dependencies between operators. The current scheduling does not consider this dependency, which is not a good design.
But the current fix does not change the implementation of this pipeline engine.
What I'm doing:
If prepare return eof, we will first
set_finishedand thenset_prepare_finished.What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist: