Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 4324ade

Browse files
committed
Fix optimization for skipping searches for parallel-query hazards.
Fix thinko in commit da1c916: even if the original query was free of parallel hazards, we might introduce such a hazard by adding PARAM_EXEC Param nodes. Adjust is_parallel_safe() so that it will scan the given expression whenever any such nodes have been created. Per report from Andreas Seltenreich. Discussion: <878tse6yvf.fsf@credativ.de>
1 parent a734fd5 commit 4324ade

File tree

1 file changed

+8
-2
lines changed

1 file changed

+8
-2
lines changed

src/backend/optimizer/util/clauses.c

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1150,8 +1150,14 @@ is_parallel_safe(PlannerInfo *root, Node *node)
11501150
{
11511151
max_parallel_hazard_context context;
11521152

1153-
/* If max_parallel_hazard found nothing unsafe, we don't need to look */
1154-
if (root->glob->maxParallelHazard == PROPARALLEL_SAFE)
1153+
/*
1154+
* Even if the original querytree contained nothing unsafe, we need to
1155+
* search the expression if we have generated any PARAM_EXEC Params while
1156+
* planning, because those are parallel-restricted and there might be one
1157+
* in this expression. But otherwise we don't need to look.
1158+
*/
1159+
if (root->glob->maxParallelHazard == PROPARALLEL_SAFE &&
1160+
root->glob->nParamExec == 0)
11551161
return true;
11561162
/* Else use max_parallel_hazard's search logic, but stop on RESTRICTED */
11571163
context.max_hazard = PROPARALLEL_SAFE;

0 commit comments

Comments
 (0)