From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andreas Seltenreich <seltenreich(at)gmx(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan |
Date: | 2016-11-25 13:18:18 |
Message-ID: | CAA4eK1LkH9TXgM_+tJ8wt9Oyj0ZitM+cVsvZq51xjXe8QSBvRA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 25, 2016 at 10:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> On Fri, Nov 25, 2016 at 3:26 AM, Andreas Seltenreich <seltenreich(at)gmx(dot)de> wrote:
>>> just caught another InitPlan below Gather with the recent patches in
>>> (master as of 4cc6a3f). Recipe below.
>
>> I think this problem exists since commit
>> 110a6dbdebebac9401b43a8fc223e6ec43cd4d10 where we have allowed
>> subqueries to be pushed to parallel workers.
>
> The impression I got in poking at this for a few minutes, before
> going off to stuff myself with turkey, was that we were allowing
> a SubqueryScanPath to mark itself as parallel-safe even though the
> resulting plan node would have an InitPlan attached. So my thought
> about fixing it was along the lines of if-subroot-contains-initplans-
> then-dont-let-SubqueryScanPath-be-parallel-safe.
>
I think this will work for the reported case, see the patch attached.
However, don't we need to worry about if there is a subplan
(non-initplan) instead of initplan. I have tried by tweaking the
above query such that it will generate a subplan and for such a case
it will make SubqueryScanPath as parallel-safe.
explain select 1 from public.quad_point_tbl as ref_0, lateral (select
ref_0.p as c3, sample_0.d as c5 from public.nv_child_2010 as sample_0
left join public.mvtest_tvv as ref_1 on ('x' = ANY (select contype
from pg_catalog.pg_constraint limit 1)) limit 82) as subq_0;
> What you propose
> here seems like it would shut off parallel query in more cases than
> that. But I'm still full of turkey and may be missing something.
>
> There's another issue here, which is that the InitPlan is derived from an
> outer join qual whose outer join seems to have been deleted entirely by
> analyzejoins.c. Up to now it was possible to avert our eyes from the fact
> that join removal is lazy about getting rid of unused InitPlans, but if
> they're going to disable parallelization of the surrounding query, maybe
> we need to work harder on that.
>
Yeah, that makes sense, but not sure whether we should try it along
with this patch.
> Another question worth asking is whether it was okay for the subquery to
> decide to use a Gather. Are we OK with multiple Gathers per plan tree,
> independently of the points above?
>
As of now, we don't support nested Gather case. Example:
Not Okay Plan
---------------------
-> Gather
-> Nested Loop
-> Parallel Seq Scan
-> Gather
-> Parallel Seq Scan
Okay Plan
---------------------
-> Nested Loop
-> Gather
-> Parallel Seq Scan
-> Gather
-> Parallel Seq Scan
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
allow_safe_subquery_parallel_worker_v2.patch | application/octet-stream | 656 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Amos Bird | 2016-11-25 13:47:37 | Re: make default TABLESPACE belong to target table. |
Previous Message | Michael Paquier | 2016-11-25 13:07:48 | Re: make default TABLESPACE belong to target table. |