Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Wed, Aug 30, 2023 at 7:42 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> When we expand Var 'c1' from func(c1), we figure out that it comes from
>> subquery 's'. When we recurse into subquery 's', we just build an
>> additional level of ParseState atop the current ParseState, which seems
>> not correct. Shouldn't we climb up by the nesting depth first before we
>> build the additional level of ParseState? Something like
>> ...

> Here is the patch.

Yeah, I think your diagnosis is correct. The existing regression tests
reach this code path, but not with netlevelsup different from zero.
I noted from the code coverage report that the same is true of the
nearby RTE_CTE code path: that does have a loop to crawl up the pstate
stack, but it isn't getting iterated. The attached improved patch
extends the test case so it also covers that.

I would have liked to also cover the RTE_JOIN case, which the code
coverage report shows to be completely untested. However, I failed
to make a test case that reached that. I think it might be a lot
harder to reach in the wake of 9ce77d75c, which narrowed the cases
in which join alias Vars are created.

I also spent a little bit of effort on improving the comments and
removing cosmetic differences between the SUBQUERY and CTE cases.

regards, tom lane