Re: BUG #19055: Server crash at ExecInterpExpr

PG Bug reporting form <noreply@postgresql.org> writes:
> PoC:
> SELECT FROM ( SELECT generate_series ( 1 , '31' ) x ) GROUP BY ( x ) WINDOW
> w AS ( ORDER BY ( WITH x AS ( WITH x AS ( SELECT sum ( x ) ) SELECT DISTINCT
> * FROM x ) ( SELECT ( count ( ( SELECT x FROM x ) ) ) ) ) )

Interesting example.  De-obfuscating a little bit, we have

SELECT 1 FROM ( SELECT generate_series ( 1 , '31' ) gs ) ss
  GROUP BY ( gs )
  WINDOW w AS ( ORDER BY (
    WITH x1 AS -- MATERIALIZED
      ( WITH x2 AS ( SELECT sum ( gs ) )
        SELECT DISTINCT * FROM x2 )
    SELECT ( count ( ( SELECT gs FROM x1 ) ) )
  ) );

If you stick in MATERIALIZED where I show, then instead of an
executor assertion failure you get
	ERROR:  could not find CTE "x1"
which is also what happens in branches pre-dating default inlining
of CTEs.

The problem appears to be that the count() aggregate is assigned the
wrong agglevelsup: it's labeled with agglevelsup = 1, implying that
it belongs to the outer query level (which is where its "gs" input
comes from).  Then when we try to pull it up to the outer level,
the contained reference to the x1 CTE becomes dangling --- the planner
can't find any x1 in that level.  Or, if we don't say MATERIALIZED,
the planner tries to inline x1 and just botches things entirely.
I suspect it's getting confused about which level "sum(gs)"
belongs to, but I didn't bother running down the details.

In any case, this is the parser's fault.  Because the count()
references x1, it should not be given an agglevelsup higher than
where x1 is.  The attached seems to fix it.  I need to think
of a test case with less extraneous crud, though...

Thanks for the report!

			regards, tom lane