database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-14 18:42:34 +03:00
Code Activity

Fix assertion failure when Parallel Append is run serially.

Browse Source 
Parallel-aware plan nodes must be prepared to run without parallelism
if it's not possible at execution time for whatever reason.  Commit
ab72716778, which introduced Parallel
Append, overlooked this.

Rajkumar Raghuwanshi reported this problem, and I included his test
case in this patch.  The code changes are by me.

Discussion: http://postgr.es/m/CAKcux6=WqkUudLg1GLZZ7fc5ScWC1+Y9qD=pAHeqy32WoeJQvw@mail.gmail.com
This commit is contained in:
Robert Haas
2018-02-28 10:56:06 -05:00
parent 4fa396464e
commit ce1663cdcd
3 changed files with 31 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
src/backend/executor/nodeAppend.c
View File

@ -162,7 +162,7 @@ ExecInitAppend(Append *node, EState *estate, int eflags)
appendstate->as_whichplan =
appendstate->ps.plan->parallel_aware ? INVALID_SUBPLAN_INDEX : 0;
/* If parallel-aware, this will be overridden later. */
/* For parallel query, this will be overridden later. */
appendstate->choose_next_subplan = choose_next_subplan_locally;
return appendstate;
@ -361,14 +361,21 @@ choose_next_subplan_locally(AppendState *node)
{
int whichplan = node->as_whichplan;
/* We should never see INVALID_SUBPLAN_INDEX in this case. */
Assert(whichplan >= 0 && whichplan <= node->as_nplans);
if (ScanDirectionIsForward(node->ps.state->es_direction))
{
if (whichplan >= node->as_nplans - 1)
return false;
node->as_whichplan++;
/*
* We won't normally see INVALID_SUBPLAN_INDEX in this case, but we
* might if a plan intended to be run in parallel ends up being run
* serially.
*/
if (whichplan == INVALID_SUBPLAN_INDEX)
node->as_whichplan = 0;
else
{
if (whichplan >= node->as_nplans - 1)
return false;
node->as_whichplan++;
}
}
else
{