Skip to content

Commit f8807e7

Browse files
committed
Consider parallel awareness when removing single-child Appends
8edd0e7 added some code to remove Append and MergeAppend nodes when they contained a single child node. As it turned out, this was unsafe to do when the Append/MergeAppend was parallel_aware and the child node was not. Removing the Append/MergeAppend, in this case, could lead to the child plan being called multiple times by parallel workers when it was unsafe to do so. Here we fix this by just not removing the Append/MergeAppend when the parallel_aware flag of the parent and child node don't match. Reported-by: Yura Sokolov Bug: #17335 Discussion: https://postgr.es/m/b59605fecb20ba9ea94e70ab60098c237c870628.camel%40postgrespro.ru Backpatch-through: 12, where 8edd0e7 was first introduced
1 parent 35893cc commit f8807e7

File tree

1 file changed

+20
-4
lines changed

1 file changed

+20
-4
lines changed

src/backend/optimizer/plan/setrefs.c

Lines changed: 20 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1359,8 +1359,16 @@ set_append_references(PlannerInfo *root,
13591359
lfirst(l) = set_plan_refs(root, (Plan *) lfirst(l), rtoffset);
13601360
}
13611361

1362-
/* Now, if there's just one, forget the Append and return that child */
1363-
if (list_length(aplan->appendplans) == 1)
1362+
/*
1363+
* See if it's safe to get rid of the Append entirely. For this to be
1364+
* safe, there must be only one child plan and that child plan's parallel
1365+
* awareness must match that of the Append's. The reason for the latter
1366+
* is that the if the Append is parallel aware and the child is not then
1367+
* the calling plan may execute the non-parallel aware child multiple
1368+
* times.
1369+
*/
1370+
if (list_length(aplan->appendplans) == 1 &&
1371+
((Plan *) linitial(aplan->appendplans))->parallel_aware == aplan->plan.parallel_aware)
13641372
return clean_up_removed_plan_level((Plan *) aplan,
13651373
(Plan *) linitial(aplan->appendplans));
13661374

@@ -1423,8 +1431,16 @@ set_mergeappend_references(PlannerInfo *root,
14231431
lfirst(l) = set_plan_refs(root, (Plan *) lfirst(l), rtoffset);
14241432
}
14251433

1426-
/* Now, if there's just one, forget the MergeAppend and return that child */
1427-
if (list_length(mplan->mergeplans) == 1)
1434+
/*
1435+
* See if it's safe to get rid of the MergeAppend entirely. For this to
1436+
* be safe, there must be only one child plan and that child plan's
1437+
* parallel awareness must match that of the MergeAppend's. The reason
1438+
* for the latter is that the if the MergeAppend is parallel aware and the
1439+
* child is not then the calling plan may execute the non-parallel aware
1440+
* child multiple times.
1441+
*/
1442+
if (list_length(mplan->mergeplans) == 1 &&
1443+
((Plan *) linitial(mplan->mergeplans))->parallel_aware == mplan->plan.parallel_aware)
14281444
return clean_up_removed_plan_level((Plan *) mplan,
14291445
(Plan *) linitial(mplan->mergeplans));
14301446

0 commit comments

Comments
 (0)