On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > > And, I'm going to revert this part. If you'd run the regression tests > under force_parallel_mode=regress, max_parallel_degree>0, you would > have noticed that this part breaks it, because of CREATE TABLE ... AS > EXECUTE. >
I have looked into this issue and found that the reason for the failure is that in force_parallel_mode=regress, we enable parallel mode restrictions even if the parallel plan is not choosen as part of below code in standard_planner()
if (force_parallel_mode == FORCE_PARALLEL_OFF || !glob->parallelModeOK)
{
glob->parallelModeNeeded = false;
glob->wholePlanParallelSafe = false;/* either false or don't care */
}
else
{
glob->parallelModeNeeded = true;
glob->wholePlanParallelSafe =
!has_parallel_hazard((Node *) parse, false);
}
The failure cases fall into that category, basically wholePlanParallelSafe will be false, but parallelModeNeeded will be true which will enable parallel mode restrictions even though the plan won't contain Gather node. I think if we want to operate in above way for testing purpose, then we need to force during execution that statements for non read-only operations should not enter into parallel mode similar to what we are doing for non-zero tuple count case. Attached patch fixes the problem.
