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

On Wed, Aug 30, 2023 at 4:06 PM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:

> PostgreSQL server subprocess crashed by a SELECT statement with WITH
> clause.
> It did not affect the main process. It can be reproduced on PostgreSQL
> 15.4.
>
> PoC:
> ```sql
> WITH x ( x ) AS ( SELECT ( 1 , 'x' ) ) SELECT FROM x WHERE ( SELECT FROM (
> SELECT x ) x WHERE ( SELECT x ( x ) ) )
> ```

Thanks for the report! Reproduced here on HEAD. I looked into it a
little bit and it seems that when we expand a Var of type RECORD from a
RTE_SUBQUERY, we mess up with the level of ParseState. For example,

select * from (SELECT(1, 'a')) as t(c)
WHERE (SELECT * FROM (SELECT c as c1) s
WHERE (select * from func(c1) f));

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

--- a/src/backend/parser/parse_target.c
+++ b/src/backend/parser/parse_target.c
@@ -1591,6 +1591,12 @@ expandRecordVariable(ParseState *pstate, Var *var,
int levelsup)
*/
ParseState mypstate = {0};

+ for (int i = 0; i < netlevelsup; i++)
+ {
+ pstate = pstate->parentParseState;
+ Assert(pstate != NULL);
+ }
+
mypstate.parentParseState = pstate;
mypstate.p_rtable = rte->subquery->rtable;

Thanks
Richard