On Sun, Oct 29, 2017 at 9:55 PM, Robert Haas wrote:
> On Sat, Oct 28, 2017 at 8:02 PM, Amit Kapila wrote:
>> I think we need to make changes in exec_simple_recheck_plan to make
>> the behavior similar to HEAD. With the attached patch, all tests
>> passed with force_parallel_mode.
>
> Committed t
On Sat, Oct 28, 2017 at 8:02 PM, Amit Kapila wrote:
> I think we need to make changes in exec_simple_recheck_plan to make
> the behavior similar to HEAD. With the attached patch, all tests
> passed with force_parallel_mode.
Committed to REL_10_STABLE.
--
Robert Haas
EnterpriseDB: http://www.en
On Sat, Oct 28, 2017 at 2:02 AM, Robert Haas wrote:
> On Mon, Oct 16, 2017 at 12:59 PM, Amit Kapila wrote:
> When I tried back-porting the patch to v10 I discovered that the
> plpgsql changes conflict heavily and that ripping them out all the way
> produces regression failures under force_paralle
On Mon, Oct 16, 2017 at 12:59 PM, Amit Kapila wrote:
>> I think the Param case should be mentioned after "... but" not before
>> - i.e. referencing the child node's output... but setrefs.c might also
>> have copied a Const or Param is-is.
>
> I am not sure if we can write the comment like that (..
On Mon, Oct 16, 2017 at 4:29 PM, Amit Kapila wrote:
> On Sat, Oct 14, 2017 at 1:51 AM, Robert Haas wrote:
>
>> I think the bug is in ExecGather(Merge): it assumes that if we're in
>> parallel mode, it's OK to start workers. But actually, it shouldn't
>> do this unless ExecutePlan ended up with u
On Sat, Oct 14, 2017 at 1:51 AM, Robert Haas wrote:
> On Fri, Oct 13, 2017 at 1:19 AM, Amit Kapila wrote:
>> After fixing this problem, when I ran the regression tests with
>> force_parallel_mode = regress, I saw multiple other failures. All the
>> failures boil down to two kinds of cases:
>>
>>
On Fri, Oct 13, 2017 at 1:19 AM, Amit Kapila wrote:
> After fixing this problem, when I ran the regression tests with
> force_parallel_mode = regress, I saw multiple other failures. All the
> failures boil down to two kinds of cases:
>
> 1. There was an assumption while extracting simple expressi
As discussed in a nearby thread [1] (parallelize queries containing
initplans), it appears that there are cases where queries referring
PARAM_EXTERN params are treated as parallel-restricted even though
they should be parallel-safe. I have done some further investigation
and found that actually fo
