Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)
Дата
Msg-id CAA4eK1Jz5tG2D2PCNYqYob2cb4dKowKYwVJ7OmP5vwyRyCMx4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Thu, May 12, 2016 at 11:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> >> Target list for a relation, you mean?  See relation.h:
> >>
> >> *      reltarget - Default Path output tlist for this rel; normally contains
> >> *                  Var and PlaceHolderVar nodes for the values we need to
> >> *                  output from this relation.
> >> *                  List is in no particular order, but all rels of an
> >> *                  appendrel set must use corresponding orders.
> >> *                  NOTE: in an appendrel child relation, may contain
> >> *                  arbitrary expressions pulled up from a subquery!
>
> > Err, wow.  That makes my head hurt.  Can you explain why this case
> > only arises for appendrel children, and not for plain rels?
>
> Well, plain rels only output Vars ;-)
>
> But consider an appendrel representing
>
>         (SELECT x+1 FROM t1 UNION ALL SELECT y+2 FROM t2) ss(a)
>
> The RTE for ss will have a reltarget list containing just "a".
> Once we pull up the subqueries, the reltarget lists for the two child
> appendrel members will need to contain "x+1" and "y+2" in order to be
> equivalent to the parent's reltarget list.  See set_append_rel_size(),
> which does that transformation.
>

I think this can also lead to an issue, as currently for child relations, we just copy consider_parallel flag of parent.  Now, if the child rel target list is adjusted such that it contains parallel restricted expression, then we are bound to fail.  I think to handle append rel case appropriately, we should compute the consider_parallel flag for each child relation in set_append_rel_size() and then later when computing the flag for parent rel, consider the flag for child rels (basically if any child rel has consider_parallel as false, then set consider_parallel for parent as false).  To achieve this, we need to call  set_rel_consider_parallel() after calling set_rel_size().

Thoughts?

Just to summarize, apart from above issue, we have discussed two different issues related to parallel query in this thread.
a. Push down of parallel restricted clauses to nodes below gather.  Patch to fix same is posted upthread [1].
b. Wrong assumption that target list can only contain Vars.  Patch to fix same is posted upthread [2].  Test which prove our assumption is wrong is also posted upthread [3].

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: foreign table batch inserts
Следующее
От: Nikolay Shaplov
Дата:
Сообщение: Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet