Thread

  1. Re: [Bug]Assertion failure in LATERAL GRAPH_TABLE with multi-label pattern

    SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-05-12T17:41:53Z

    HI,
    
    On Tue, May 12, 2026 at 4:15 AM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
    wrote:
    
    > On Thu, May 7, 2026 at 9:43 AM SATYANARAYANA NARLAPURAM
    > <satyanarlapuram@gmail.com> wrote:
    > >
    > > Hi hackers,
    > >
    > > A LATERAL GRAPH_TABLE whose pattern matches more than one path query
    > > fails with the assert
    > >
    > > TRAP: failed Assert("!bms_is_member(rti, lateral_relids)"), File:
    > "initsplan.c", Line: 1428, PID: 3586144
    > > postgres: postgres postgres [local]
    > SELECT(ExceptionalCondition+0x70)[0x63488e3cc070]
    > > postgres: postgres postgres [local]
    > SELECT(create_lateral_join_info+0x468)[0x63488e14ac28]
    > > postgres: postgres postgres [local]
    > SELECT(query_planner+0x13a)[0x63488e14dfca]
    > >
    > > Repro:
    > > SELECT v1.vname, gt.aname
    > >   FROM v1, LATERAL (SELECT * FROM GRAPH_TABLE (g1 MATCH (a IS vl1 | vl2
    > WHERE a.vprop1 = v1.vprop1) COLUMNS (a.vname AS aname)) g) gt
    > >   ORDER BY 1, 2;
    > >
    > > Single-label GRAPH_TABLE with the same outer reference works fine.
    > > rewriteGraphTable() turns the GRAPH_TABLE RTE into a subquery RTE and
    > > bumps outer Vars by one sublevel.  When the pattern produces multiple
    > > path queries, generate_setop_from_pathqueries() wraps each one in
    > > another subquery RTE for the UNION ALL but does not bump again, so the
    > > lateral reference collapses onto GRAPH_TABLE's own RTE.
    >
    > + /* Wrapping lquery in a subquery RTE adds one query level, so bump
    > + * outer-level Vars accordingly. */
    > + IncrementVarSublevelsUp((Node *) lquery, 1, 1);
    > +
    >
    > Multiline comments start with /* and end with */ on separate lines
    > respectively.
    >
    > From the comment it feels like we will add as many varlevels as the
    > depth of setop tree, since we will add a subquery RTE for each setop
    > level. In reality all the legs of the setop tree will be at the same
    > varlevel. A better comment would be "Vars in each path query are one
    > level away from the setop query combining them.".
    >
    > The connection between varlevelsup, addition of subquery RTE and the
    > assertion failure isn't clear. Assertion failure indicates that the
    > relation being examined has lateral reference to itself which boils
    > down to range table entry index but the varlevelsup is about depth of
    > a given query. The connection between these two seemingly different
    > things needs to be explained in the commit message. Though the code
    > changes fix the problem, there may be a better place to increment
    > varlevels up. That will be clear once the connection is clear.
    >
    > >
    > > Tried fixing this by bumping each lquery's sublevels by 1 before the
    > addRangeTableEntry
    > > ForSubquery() wrap.  Single-pathquery queries skip this path entirely.
    > >
    > > Attached a patch with the tests.
    > >
    >
    > Do we need both the tests? The second one has no label expression
    > which means it will try all the labels. So the test will reproduce the
    > bug only when there are multiple labels. The first test explicitly
    > adds the multi-label pattern. I think we should just leave the first
    > one and remove the second one. Also this test should be placed in the
    > section which tests other lateral references. myshop property graph
    > has two sets of elements that share a label - order and wishlist,
    > order_items and wishlist_items.
    >
    
    Thanks for reviewing, will address the comments shortly.