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

On Thu, May 12, 2016 at 11:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)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].

I will add this issue in list of open issues for 9.6 @
https://wiki.postgresql.org/wiki/PostgreSQL_9.6_Open_Items

[1] -
https://www.postgresql.org/message-id/CAA4eK1Ky2=HsTsT4hmfL=EAL5rv0_t59tvWzVK9HQKvN6Dovkw@mail.gmail.com
[2] -
https://www.postgresql.org/message-id/CAA4eK1L-Uo=s4=0jvvVA51pj06u5WdDvSQg673yuxJ_Ja+x86Q@mail.gmail.com
[3] -
https://www.postgresql.org/message-id/CAFiTN-vzg5BkK6kAh3OMhvgRu-uJvkjz47ybtopMAfGJp=zWqA@mail.gmail.com

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com