Skip to content

pipeline: global LIMIT can hang right outer join by skipping finishOneProbe #11088

Description

@windtalker

Problem

In the pipeline execution model, a global LIMIT downstream of a hash join may finish one probe pipeline before that probe source reaches EOF. For joins that must scan the build-side hash map after all probes complete, the early-finished probe never calls Join::finishOneProbe().

Other probe streams can reach EOF, call finishOneProbe(), and then wait forever for wait_probe_finished_future, because active_probe_threads never reaches zero.

This can leave the root MPP task and its exchange sender waiting indefinitely. The production case was observed on v8.5.4.

Affected Join Modes

The reproducer covers RightOuter. The same lifecycle requirement is used by the join modes where needScanHashMapAfterProbe() is true, including full outer, right semi, and right anti joins.

Deterministic Reproducer

A minimal pipeline gtest was added locally:

JoinExecutorTestRunner.PipelineRightOuterJoinLimitMaySkipProbeFinish

It builds a two-stream probe side for a RIGHT OUTER JOIN ... LIMIT 1:

  • Probe stream A has two one-row blocks and produces the row that reaches the global limit.
  • Probe stream B immediately reaches EOF.
  • A test-only failpoint pauses B immediately after it calls finishOneProbe(), allowing A to be stopped by LIMIT before it reaches EOF.
  • After releasing the failpoint, B transitions to WAIT_PROBE_FINISH and cannot make progress because A never decremented the active-probe count.

The test explicitly calls query_executor->cancel() for cleanup. Without cancellation it does not complete.

A 60-second verification run showed:

11:19:48.442  PROBE -> WAIT_PROBE_FINISH
11:20:48.448  cancellation starts cleanup
wait_for_notify_time_ns = 60,005,557,000

The query had no natural progress for the full 60-second post-failpoint observation window.

Expected Behavior

Early downstream completion caused by global LIMIT must not leave a join waiting for a probe stream that will never receive source EOF. The query should complete naturally without requiring query cancellation.

Possible Direction

Make pipeline early-stop propagation join-aware: when a downstream sink finishes and an unfinished probe will no longer be driven to EOF, ensure the join records that probe as finished or otherwise resolves the scan-after-probe wait. The fix must correctly wake the wait_probe_finished_future, not only condition-variable waiters.

Regression Coverage

Once fixed, the reproducer should be inverted to assert natural query completion under the same forced scheduling order.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions