On Fri, Jul 1, 2016 at 5:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andreas Seltenreich <seltenreich@gmx.de> writes:
>> Updating master from f8c5855..1bdae16, sqlsmith triggers "failed to
>> generate plan" errors again. Below is the smallest query logged so far.
>
> Hmm, interesting. This can be reduced to
>
> set force_parallel_mode = on;
>
> explain
> with j1 as (select * from int8_tbl)
> select * from int4_tbl
> where false and EXISTS (select 1 as c0 from j1);
>
> The "plan should not reference subplan's variable" fail seems to be due
> to ancient fuzzy thinking in SS_finalize_plan. When I fix that, I get
> a plan like so:
>
> Gather (cost=0.00..0.00 rows=0 width=0)
> Workers Planned: 1
> Single Copy: true
> -> Result (cost=1.05..1.05 rows=0 width=4)
> One-Time Filter: false
> CTE j1
> -> Seq Scan on int8_tbl (cost=0.00..1.05 rows=5 width=16)
>
> but if I try to actually execute the query, it crashes at runtime,
> apparently because the CTE has not been passed over to the parallel
> worker. Robert, is it expected that CTEs should be parallel-safe?
> I'd have thought not.
Not. See the RTE_CTE case in set_rel_consider_parallel.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company