On Fri, Jul 1, 2016 at 5:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Andreas Seltenreich <seltenre...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to