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: http://www.postgresql.org/mailpref/pgsql-hackers
