HI, On Tue, May 12, 2026 at 4:15 AM Ashutosh Bapat <[email protected]> wrote:
> On Thu, May 7, 2026 at 9:43 AM SATYANARAYANA NARLAPURAM > <[email protected]> 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.
