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

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [Bug]Assertion failure in LATERAL GRAPH_TABLE with multi-label pattern
Date: 2026-06-05 09:38:04
Message-ID: CAExHW5vqPUL-WiNohHZYPp_yO45gSkkcLKqD73=Q8D7c-PM-pA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 5, 2026 at 1:05 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 02.06.26 13:02, Ashutosh Bapat wrote:
> > Yes, fix is at the right place. 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.
> >
> > Depending upon the varno of outer reference we will see different
> > symptoms. a crash or an error "plan should not reference subplan's
> > variable" or even data type mismatch. Also the levelsup is maintained
> > in nodes other than Var. I have modified the commit message to focus
> > on the problem instead of the symptom. Also some small edits to the
> > comments.
> >
> > Attached patch has the number 0010 (vs 0001) since I am creating
> > patches for all the SQL/PGQ fixes from the same branch. It can be
> > applied independent of other patches.
>
> committed

Thanks a lot.

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-06-05 09:45:28 Re: Unexpected message truncation in WaitForAllTransactionsToFinish
Previous Message shveta malik 2026-06-05 09:36:13 Re: Proposal: Conflict log history table for Logical Replication