Horton

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

Richard Guo <guofenglinux@gmail.com>

View thread View on postgr.es
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: fuboat@outlook.com, pgsql-bugs@lists.postgresql.org
Date: 2023-09-04T03:01:41Z
Lists: pgsql-bugs 
On Sat, Sep 2, 2023 at 4:41 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Richard Guo <guofenglinux@gmail.com> writes:
> > On Wed, Aug 30, 2023 at 7:42 PM Richard Guo <guofenglinux@gmail.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.


+1 to the v2 patch.

BTW, do you think get_name_for_var_field() has similar problem for
RTE_SUBQUERY case?  The RTE_CTE code path in that function crawls up the
namespace stack before recursing into the CTE while the RTE_SUBQUERY
code patch does not, which looks like an oversight.  I tried to find a
test case to show it's indeed a problem but with no luck.

Thanks
Richard

Commits

  1. Track nesting depth correctly when drilling down into RECORD Vars.

  2. Fix get_expr_result_type() to find field names for RECORD Consts.

  3. Allow extracting fields from a ROW() expression in more cases.