Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause - Mailing list pgsql-bugs

From Richard Guo
Subject Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause
Date
Msg-id CAMbWs4_zxFFSy8+6-FG2ZdJc91TQGM+yG0Yh7gydhjTQfb=9fg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs

On Wed, Aug 30, 2023 at 7:42 PM Richard Guo <guofenglinux@gmail.com> wrote:
On Wed, Aug 30, 2023 at 4:06 PM PG Bug reporting form <noreply@postgresql.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
Attachment

pgsql-bugs by date:

Previous
From: Richard Guo
Date:
Subject: Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause
Next
From: Tom Lane
Date:
Subject: Re: BUG #18076: Consistently receiving Signal 7 and Signal 11 errors