public inbox for [email protected]  
help / color / mirror / Atom feed
From: Ayush Tiwari <[email protected]>
To: SATYANARAYANA NARLAPURAM <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: [Bug]Assertion failure in LATERAL GRAPH_TABLE with multi-label pattern
Date: Tue, 19 May 2026 20:45:50 +0530
Message-ID: <CAJTYsWV8pnPjPSPeoM=RLzR=iqJB0Zt2VJviZrk9voQrvTfpcQ@mail.gmail.com> (raw)
In-Reply-To: <CAHg+QDciGLJv3KQ7k5ABpRocgMXAiX787trr8ehdyjUrNue4rw@mail.gmail.com>
References: <CAHg+QDfnLzsgjaQ_CiKSpP4JH3MKOiwoawEcCzXa9uYr45yiWw@mail.gmail.com>
	<CAExHW5tfeOhH7_SkNKhAJvBm4VtLq7Oh60E+h7S0T_rkJJi_Yw@mail.gmail.com>
	<CAHg+QDciGLJv3KQ7k5ABpRocgMXAiX787trr8ehdyjUrNue4rw@mail.gmail.com>

--00000000000036d45006522d2826
Content-Type: multipart/alternative; boundary="00000000000036d45006522d2824"

--00000000000036d45006522d2824
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, 12 May 2026 at 23:12, SATYANARAYANA NARLAPURAM <
[email protected]> wrote:

> HI,
>
> On Tue, May 12, 2026 at 4:15=E2=80=AFAM Ashutosh Bapat <
> [email protected]> wrote:
>
>> On Thu, May 7, 2026 at 9:43=E2=80=AFAM 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 | vl=
2
>> WHERE a.vprop1 =3D 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.
>
Attached is v2 of Satya's patch, addressing the review comments.

Changes in v2:

- Reworded the inline comment in PostgreSQL multi-line style. It now
explains
  that each path query is inserted as a subquery RTE of the setop query, so
  Vars that already refer outside the path query must be adjusted for the
  additional query level. Local Vars belonging to the path query are
  unchanged (the call uses min_sublevels_up =3D 1).

- Expanded the commit message to spell out the connection between the
missing
  varlevelsup adjustment and the lateral self-reference assertion.

- Reduced the regression coverage to a single explicit multi-label case, an=
d
  moved it next to the existing lateral-reference tests rather than at the
  end of the file.

The fix is kept at the same place (generate_setop_from_pathqueries), since
that is where the extra subquery RTE wrapping happens. Doing it any earlier
would over-adjust the single-pathquery path.

Regards,
Ayush

--00000000000036d45006522d2824
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 12 May 2=
026 at 23:12, SATYANARAYANA NARLAPURAM &lt;<a href=3D"mailto:satyanarlapura=
[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">HI,=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Tue, May 12, 2026 at 4:15=E2=80=AFAM Ashutosh Bapat &lt;<a href=3D"mailt=
o:[email protected]" target=3D"_blank">ashutosh.bapat.oss@gmail.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">On Thu, May 7, 2026 at 9:43=E2=80=AFAM SATYANARAYANA NARLAPURAM<br>
&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">satyanar=
[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi hackers,<br>
&gt;<br>
&gt; A LATERAL GRAPH_TABLE whose pattern matches more than one path query<b=
r>
&gt; fails with the assert<br>
&gt;<br>
&gt; TRAP: failed Assert(&quot;!bms_is_member(rti, lateral_relids)&quot;), =
File: &quot;initsplan.c&quot;, Line: 1428, PID: 3586144<br>
&gt; postgres: postgres postgres [local] SELECT(ExceptionalCondition+0x70)[=
0x63488e3cc070]<br>
&gt; postgres: postgres postgres [local] SELECT(create_lateral_join_info+0x=
468)[0x63488e14ac28]<br>
&gt; postgres: postgres postgres [local] SELECT(query_planner+0x13a)[0x6348=
8e14dfca]<br>
&gt;<br>
&gt; Repro:<br>
&gt; SELECT v1.vname, gt.aname<br>
&gt;=C2=A0 =C2=A0FROM v1, LATERAL (SELECT * FROM GRAPH_TABLE (g1 MATCH (a I=
S vl1 | vl2 WHERE a.vprop1 =3D v1.vprop1) COLUMNS (a.vname AS aname)) g) gt=
<br>
&gt;=C2=A0 =C2=A0ORDER BY 1, 2;<br>
&gt;<br>
&gt; Single-label GRAPH_TABLE with the same outer reference works fine.<br>
&gt; rewriteGraphTable() turns the GRAPH_TABLE RTE into a subquery RTE and<=
br>
&gt; bumps outer Vars by one sublevel.=C2=A0 When the pattern produces mult=
iple<br>
&gt; path queries, generate_setop_from_pathqueries() wraps each one in<br>
&gt; another subquery RTE for the UNION ALL but does not bump again, so the=
<br>
&gt; lateral reference collapses onto GRAPH_TABLE&#39;s own RTE.<br>
<br>
+ /* Wrapping lquery in a subquery RTE adds one query level, so bump<br>
+ * outer-level Vars accordingly. */<br>
+ IncrementVarSublevelsUp((Node *) lquery, 1, 1);<br>
+<br>
<br>
Multiline comments start with /* and end with */ on separate lines respecti=
vely.<br>
<br>


reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [Bug]Assertion failure in LATERAL GRAPH_TABLE with multi-label pattern
  In-Reply-To: <CAJTYsWV8pnPjPSPeoM=RLzR=iqJB0Zt2VJviZrk9voQrvTfpcQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox