[Bug]Assertion failure in LATERAL GRAPH_TABLE with multi-label pattern

First seen: 2026-05-07 04:13:20+00:00 · Messages: 5 · Participants: 3

Latest Update

2026-06-04 · claude-opus-4-6

Monthly Summary: Assertion Failure in LATERAL GRAPH_TABLE with Multi-label Pattern (May 2026)

Overview

A bug was reported and fixed in PostgreSQL's SQL/PGQ GRAPH_TABLE implementation where a LATERAL reference into a GRAPH_TABLE using multi-label patterns (e.g., a IS vl1 | vl2) triggers an assertion failure in the planner's create_lateral_join_info(). The fix progressed from initial diagnosis through patch v2 during this month.

Root Cause

When GRAPH_TABLE patterns use label alternation, rewriteGraphTable() expands them into multiple path queries combined via UNION ALL through generate_setop_from_pathqueries(). This introduces two levels of subquery nesting (one per-branch wrapper + one overall setop wrapper), but the rewriter only bumped varlevelsup on outer-referencing Vars once — correct for the single-path case but insufficient for multi-path expansion.

The under-bumped Var causes the lateral dependency to resolve to the GRAPH_TABLE's own RTE rather than the intended outer relation, producing a self-referential lateral dependency. The planner catches this via:

Assert(!bms_is_member(rti, lateral_relids));  /* initsplan.c:1428 */

On non-assert builds, this would silently produce wrong plans or wrong results.

The Fix

The fix calls IncrementVarSublevelsUp() with min_sublevels_up = 1 on each path query before it is wrapped into a subquery RTE during UNION ALL construction. This ensures only lateral-referencing Vars (those already pointing outside the path query) get bumped, while path-query-local Vars remain unaffected. The fix is placed inside generate_setop_from_pathqueries() itself — the function that introduces the extra wrapper is responsible for compensating varlevelsup.

Patch Progression

v1 (Satya Narlapuram): Initial fix with correct approach but minor style issues.
Style review (Ashutosh Bapat): Flagged non-standard multi-line comment formatting.
v2 (Ayush Tiwari): Reformatted comments to PostgreSQL style, expanded commit message with full causal explanation, relocated regression test adjacent to existing lateral-reference tests. Patch appears to be converging toward commit readiness.

Status at Month End

No objections or alternative approaches have been raised. The patch is awaiting further review but appears technically sound and ready for commit consideration.

History (1 prior analysis)

2026-06-04 · claude-opus-4-6

Incremental Update: Ashutosh Bapat Posts Revised Patch (v3/0010) with Broadened Problem Description

Ashutosh Bapat has taken over patch maintenance and posted an updated version (numbered 0010 in his SQL/PGQ fix series) with substantive changes to the commit message and minor code comment edits.

What's New

1. Broadened Problem Characterization

Ashutosh explicitly confirms the fix location is correct and explains why it cannot be done earlier:

"We can not set the varlevelsup to the correct value in replace_properties_references itself because when that function is called, we do not know whether UNION is required or not. The next place to adjust varlevelsup is when creating a UNION statement."

This is a new architectural insight — it clarifies the ordering constraint in the rewrite pipeline: property-reference replacement happens before the decision to create a UNION ALL, so it cannot anticipate the extra nesting level.

2. Expanded Symptom Analysis

Ashutosh notes the assertion failure is just one possible symptom depending on which varno the outer reference resolves to:

Crash (the reported assertion failure)
Error: "plan should not reference subplan's variable"
Data type mismatch errors

This broadens the understanding of the bug's impact — on non-assert builds, the bug could manifest as different runtime errors or potentially wrong results rather than always crashing.

3. levelsup Affects More Than Just Var Nodes

Ashutosh observes: "the levelsup is maintained in nodes other than Var." This implies the fix (using IncrementVarSublevelsUp) must also handle Aggref.agglevelsup, SubLink/SubPlan references, and potentially GroupingFunc.agglevelsup. The canonical IncrementVarSublevelsUp() walker already handles these cases, but Ashutosh's mention suggests he verified this coverage.

4. Commit Message Rewritten to Focus on Root Cause

The commit message now describes the problem (incorrect varlevelsup in the multi-path UNION expansion) rather than the symptom (assertion failure). This is a meaningful editorial improvement for the git history.

5. Patch Independence Confirmed

Ashutosh confirms the patch can be applied independently of other SQL/PGQ fixes despite being numbered 0010 in his series. This is relevant for commit logistics.

No Technical Objections or Alternative Approaches

The fix approach remains unchallenged. The thread appears to be converging on commit readiness with Ashutosh now shepherding the patch.