pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
[sqlsmith] ERROR:  plan should not reference subplan's variable
6+ messages / 3 participants
[nested] [flat]

Commits from this thread:
  2018-08-11 4a2994f055 0ff8f521d4  Fix wrong order of operations in inheritance_planner.
* [sqlsmith] ERROR:  plan should not reference subplan's variable
@ 2016-07-01 19:31 Andreas Seltenreich <seltenreich@gmx.de>
  2016-07-01 21:29 ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 6+ messages in thread

From: Andreas Seltenreich @ 2016-07-01 19:31 UTC (permalink / raw)
  To: pgsql-hackers

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



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: [sqlsmith] ERROR: plan should not reference subplan's variable
  2016-07-01 19:31 [sqlsmith] ERROR:  plan should not reference subplan's variable Andreas Seltenreich <seltenreich@gmx.de>
@ 2016-07-01 21:29 ` Tom Lane <tgl@sss.pgh.pa.us>
  2016-07-01 22:18   ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Robert Haas <robertmhaas@gmail.com>
  0 siblings, 1 reply; 6+ messages in thread

From: Tom Lane @ 2016-07-01 21:29 UTC (permalink / raw)
  To: Andreas Seltenreich <seltenreich@gmx.de>; +Cc: Robert Haas <robertmhaas@gmail.com>; pgsql-hackers

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.

			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



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: [sqlsmith] ERROR: plan should not reference subplan's variable
  2016-07-01 19:31 [sqlsmith] ERROR:  plan should not reference subplan's variable Andreas Seltenreich <seltenreich@gmx.de>
  2016-07-01 21:29 ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>
@ 2016-07-01 22:18   ` Robert Haas <robertmhaas@gmail.com>
  2016-07-01 22:52     ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 6+ messages in thread

From: Robert Haas @ 2016-07-01 22:18 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andreas Seltenreich <seltenreich@gmx.de>; pgsql-hackers

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


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



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: [sqlsmith] ERROR: plan should not reference subplan's variable
  2016-07-01 19:31 [sqlsmith] ERROR:  plan should not reference subplan's variable Andreas Seltenreich <seltenreich@gmx.de>
  2016-07-01 21:29 ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>
  2016-07-01 22:18   ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Robert Haas <robertmhaas@gmail.com>
@ 2016-07-01 22:52     ` Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2016-07-01 22:52 UTC (permalink / raw)
  To: Robert Haas <robertmhaas@gmail.com>; +Cc: Andreas Seltenreich <seltenreich@gmx.de>; pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 1, 2016 at 5:29 PM, Tom Lane <tgl@sss.pgh.pa.us> 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



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* [sqlsmith] ERROR:  plan should not reference subplan's variable
@ 2018-08-11 15:45 Andreas Seltenreich <seltenreich@gmx.de>
  2018-08-11 19:15 ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 6+ messages in thread

From: Andreas Seltenreich @ 2018-08-11 15:45 UTC (permalink / raw)
  To: pgsql-hackers

Hi,

sqlsmith caused another internal error while testing REL_11_STABLE at
1b9d1b08fe.  The query below on the regression DB yields "plan should
not reference subplan's variable" for me.

regards,
Andreas

delete from public.prt1_l
where
EXISTS (
  select
    from
      public.xmltest as ref_10 ,
      lateral (select
	    ref_10.data as c0
	  from
	    public.radix_text_tbl as ref_0,
	    lateral (select
		  ref_11.name as c0
		from
		  public.equipment_r as ref_11
		limit 134) as subq_0
	  limit 110) as subq_1
    where public.prt1_l.c is NULL)
returning 42;




^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: [sqlsmith] ERROR: plan should not reference subplan's variable
  2018-08-11 15:45 [sqlsmith] ERROR:  plan should not reference subplan's variable Andreas Seltenreich <seltenreich@gmx.de>
@ 2018-08-11 19:15 ` Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 6+ messages in thread

From: Tom Lane @ 2018-08-11 19:15 UTC (permalink / raw)
  To: Andreas Seltenreich <seltenreich@gmx.de>; +Cc: pgsql-hackers

Andreas Seltenreich <seltenreich@gmx.de> writes:
> sqlsmith caused another internal error while testing REL_11_STABLE at
> 1b9d1b08fe.  The query below on the regression DB yields "plan should
> not reference subplan's variable" for me.

Thanks for the report.  Seems to be wrong order of operations in
inheritance_planner: it shouldn't be appending extra SUBQUERY_RTE copies
to a subroot that it's going to use as a parent for later iterations.
That results in too many copies of the subqueries and screwed-up RTE
numbering in the children.

			regards, tom lane




^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2018-08-11 19:15 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-07-01 19:31 [sqlsmith] ERROR:  plan should not reference subplan's variable Andreas Seltenreich <seltenreich@gmx.de>
2016-07-01 21:29 ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>
2016-07-01 22:18   ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Robert Haas <robertmhaas@gmail.com>
2016-07-01 22:52     ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>
2018-08-11 15:45 [sqlsmith] ERROR:  plan should not reference subplan's variable Andreas Seltenreich <seltenreich@gmx.de>
2018-08-11 19:15 ` Re: [sqlsmith] ERROR: plan should not reference subplan's variable Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox