Re: [HACKERS] [sqlsmith] ERROR: plan should not reference subplan's variable
Robert Haas writes: > On Fri, Jul 1, 2016 at 5:29 PM, Tom Lane wrote: >> ... 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. OK; but this is crashing anyway, because after const-simplification the CTE isn't actually referenced anywhere. But it still ends up as an initplan attached to the top plan node. This may have accidentally failed to fail before you removed this bit in 5ce5e4a12: if (glob->subplans != NULL) glob->wholePlanParallelSafe = false; I think in the current code, the equivalent thing is that we need to consider that a plan node is parallel-unsafe once we've stuck some initPlans on it (which happens only in createplan.c and so doesn't affect the parallel_safe state of the source Path). Will see if that helps. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [sqlsmith] ERROR: plan should not reference subplan's variable
On Fri, Jul 1, 2016 at 5:29 PM, Tom Lane wrote: > Andreas Seltenreich 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
Re: [HACKERS] [sqlsmith] ERROR: plan should not reference subplan's variable
Andreas Seltenreich 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [sqlsmith] ERROR: plan should not reference subplan's variable
Updating master from f8c5855..1bdae16, sqlsmith triggers "failed to generate plan" errors again. Below is the smallest query logged so far. regards, Andreas -- ERROR: plan should not reference subplan's variable set force_parallel_mode = 'on'; set max_parallel_workers_per_gather = '1'; explain WITH jennifer_0 AS (select (select b from public.rtest_v1 limit 1 offset 5) as c0, pg_catalog.pg_current_xlog_location() as c1, sample_0.a as c2, sample_0.a as c3 from public.rtest_view4 as sample_0 tablesample system (5.9) where cast(null as bigint) = pg_catalog.hashinet( cast((select client_addr from pg_catalog.pg_stat_activity limit 1 offset 35) as inet)) limit 76) select ref_0.sl_name as c0 from public.shoelace as ref_0 where (cast(null as anyrange) < cast(null as anyrange)) and (EXISTS ( select 39 as c0 from jennifer_0 as ref_1 where cast(null as real) = cast(null as real) limit 81)) limit 96; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
