github-actions[bot] commented on code in PR #65928:
URL: https://github.com/apache/doris/pull/65928#discussion_r3631950850
##########
be/src/runtime/fragment_mgr.cpp:
##########
@@ -567,50 +568,52 @@ Status FragmentMgr::_get_or_create_query_ctx(const
TPipelineFragmentParams& para
}
std::string FragmentMgr::dump_pipeline_tasks(int64_t duration) {
+ std::vector<std::shared_ptr<PipelineFragmentContext>> contexts;
Review Comment:
[P1] Avoid retaining every fragment for the whole dump
This all-shard `vector<shared_ptr<...>>` makes the slowest diagnostic hold
every captured PFC alive. After `remove_pipeline_context()` erases an unrelated
completed context, its destructor still cannot run until this function returns;
that destructor drives `_release_resource()` callbacks, and recursive-CTE
`WAIT_FOR_DESTROY` deliberately stores its RPC `ClosureGuard` in the PFC so
`REBUILD` waits for destruction. Because the following formatting can block on
fragment/task/dependency locks (the reason for this PR), one stuck dump entry
can now delay finish callbacks or recursive-CTE progress for contexts on every
shard. Please snapshot weak references/keys and promote one PFC only while
formatting it (as `QueryContext::print_all_pipeline_context()` already does),
or otherwise avoid retaining all shards across the full formatting pass.
--
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]
