Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: BUG #18953: Planner fails to build plan for complex query with LATERAL references
Date: 2025-06-26 18:37:57
Message-ID: 1487176.1750963077@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> I've managed to discover one more anomaly introduced by a16ef313f, that is
> not fixed by fix-bug-18953-some-more:

Just to note that I am studying this. It looks to me like the
issue is that identify_current_nestloop_params() is handing back
a PHV with too few nullingrel bits set for the place that we want
to put it, as is acknowledged to be possible in its comments.
We thought we could get away with that, but in this context setrefs.c
will complain. I'm inclined to try to make it set the bits more
accurately, rather than further weaken setrefs.c's cross-checks.

I'm wondering again whether this isn't a case that is reachable
before a16ef313f. Perhaps the have_dangerous_phv check prevented
forming plan trees that could have this issue, but it's not real
clear why.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dilip Kumar 2025-06-27 05:05:23 Re: BUG #18961: Race scenario where max_standby_streaming_delay is not honored
Previous Message Nathan Bossart 2025-06-25 16:06:05 Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist