Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitf9a74c1

Browse files
committed
Consider parallel awareness when removing single-child Appends
8edd0e7 added some code to remove Append and MergeAppend nodes when theycontained a single child node. As it turned out, this was unsafe to dowhen the Append/MergeAppend was parallel_aware and the child node was not.Removing the Append/MergeAppend, in this case, could lead to the child planbeing called multiple times by parallel workers when it was unsafe to doso.Here we fix this by just not removing the Append/MergeAppend when theparallel_aware flag of the parent and child node don't match.Reported-by: Yura SokolovBug: #17335Discussion:https://postgr.es/m/b59605fecb20ba9ea94e70ab60098c237c870628.camel%40postgrespro.ruBackpatch-through: 12, where8edd0e7 was first introduced
1 parent741bd32 commitf9a74c1

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
@@ -1512,8 +1512,16 @@ set_append_references(PlannerInfo *root,
15121512
lfirst(l)=set_plan_refs(root, (Plan*)lfirst(l),rtoffset);
15131513
}
15141514

1515-
/* Now, if there's just one, forget the Append and return that child */
1516-
if (list_length(aplan->appendplans)==1)
1515+
/*
1516+
* See if it's safe to get rid of the Append entirely. For this to be
1517+
* safe, there must be only one child plan and that child plan's parallel
1518+
* awareness must match that of the Append's. The reason for the latter
1519+
* is that the if the Append is parallel aware and the child is not then
1520+
* the calling plan may execute the non-parallel aware child multiple
1521+
* times.
1522+
*/
1523+
if (list_length(aplan->appendplans)==1&&
1524+
((Plan*)linitial(aplan->appendplans))->parallel_aware==aplan->plan.parallel_aware)
15171525
returnclean_up_removed_plan_level((Plan*)aplan,
15181526
(Plan*)linitial(aplan->appendplans));
15191527

@@ -1576,8 +1584,16 @@ set_mergeappend_references(PlannerInfo *root,
15761584
lfirst(l)=set_plan_refs(root, (Plan*)lfirst(l),rtoffset);
15771585
}
15781586

1579-
/* Now, if there's just one, forget the MergeAppend and return that child */
1580-
if (list_length(mplan->mergeplans)==1)
1587+
/*
1588+
* See if it's safe to get rid of the MergeAppend entirely. For this to
1589+
* be safe, there must be only one child plan and that child plan's
1590+
* parallel awareness must match that of the MergeAppend's. The reason
1591+
* for the latter is that the if the MergeAppend is parallel aware and the
1592+
* child is not then the calling plan may execute the non-parallel aware
1593+
* child multiple times.
1594+
*/
1595+
if (list_length(mplan->mergeplans)==1&&
1596+
((Plan*)linitial(mplan->mergeplans))->parallel_aware==mplan->plan.parallel_aware)
15811597
returnclean_up_removed_plan_level((Plan*)mplan,
15821598
(Plan*)linitial(mplan->mergeplans));
15831599

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp