Reduce SBE pipeline lowering limit to prevent PGO-exposed stack overflow

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • 9.0.2
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Execution
    • ALL
    • QE 2026-09-15
    • 200
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      BF-46094 exposed a stack-overflow risk in recursive SBE aggregation lowering on ARM64 after the SERVER-110427 PGO profile refresh.

      The failing test constructs a legal 1,000-stage aggregation pipeline. Each $group is lowered through SlotBasedStageBuilder::buildGroup(), which recursively calls build() for the child. The PGO/BOLT layout change appears to move the optimized binary across the stack-use threshold; the failure surfaces in computeChildReqsForGroup()/PlanStageReqs::setResultObj() as an invalid access / SIGSEGV.

      Evidence:

      Request:
      Reduce the effective SBE aggregation pipeline lowering threshold from the current 1,000-stage limit to 100 stages, or implement an equivalent SBE-specific lowering cap with a safe fallback to classic execution. Preserve the documented 1,000-stage pipeline behavior where feasible, but do not allow deep recursive SBE lowering to exhaust the thread stack.

      Acceptance criteria:

      • query_limits_test.js passes on the affected ARM64 optimized and all-feature-flags variants with the current PGO/BOLT build.
      • A deep pipeline cannot trigger a stack-guard-page fault during SBE lowering.
      • Add or update regression coverage for the safe SBE lowering depth and document any compatibility impact of lowering the effective SBE cap.

        Additional context and tradeoff

      AI generated explainer

      Tradeoff: lowering the SBE lowering-depth cap intentionally limits SBE pushdown for unusually deep pipelines. Stages beyond the cap remain in Classic, so this can reduce SBE runtime and PGO coverage for those deep shapes in exchange for stack safety. It does not prevent the compiler from optimizing SBE functions globally or affect pipelines within the safe bound.

      If this tradeoff is unacceptable, the long-term fix is an iterative SBE stage-builder refactor rather than a lower cap.

            Assignee:
            Evan Bergeron
            Reporter:
            Jawwad Asghar
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: