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

On Wed, Aug 30, 2023 at 7:42 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:

> 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;
>

Here is the patch.

Thanks
Richard