yiguolei commented on code in PR #68610:
URL: https://github.com/apache/doris/pull/68610#discussion_r4254029114
##########
be/src/exec/scan/scanner_context.cpp:
##########
@@ -604,6 +604,14 @@ bool ScannerContext::can_admit_scan_task(const
std::unique_lock<std::mutex>& tra
if (done() || _pending_tasks.empty()) {
return false;
}
+ // Same rule as _pull_next_scan_task() on the TaskExecutor path: once the
shared LIMIT is
+ // exhausted, pending scanners would only open and immediately report EOS,
so do not admit
+ // them while a completed or in-flight task can still wake the operator.
If neither exists,
+ // admit one so it can report EOS and wake the pipeline task.
+ if (_is_shared_scan_limit_exhausted() &&
Review Comment:
if (_completed_tasks.empty() &&
(_num_finished_scanners == _all_scanners.size() ||
(_is_shared_scan_limit_exhausted() && _in_flight_tasks_num == 0))) {
_set_scanner_done();
_is_finished = true;
} else if (scan_task != nullptr) {
// Check the terminal state before scheduling more work. In
particular, after the shared
// LIMIT is exhausted, submitting another Context runnable can turn
a completed query into
// a queue-capacity error even though there is no result left to
drain.
RETURN_IF_ERROR(_scanner_scheduler->schedule_scan_task(
shared_from_this(), scan_task->is_eos() ? nullptr :
scan_task, l));
}
类似这个bug，容易搞出问题
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
