From 4324ade9a6880113b08070305482ace2e8a2617c Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 21 Nov 2016 13:19:14 -0500 Subject: [PATCH] Fix optimization for skipping searches for parallel-query hazards. Fix thinko in commit da1c91631: 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> --- src/backend/optimizer/util/clauses.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c index 1688310b80..9598f28bab 100644 --- a/src/backend/optimizer/util/clauses.c +++ b/src/backend/optimizer/util/clauses.c @@ -1150,8 +1150,14 @@ is_parallel_safe(PlannerInfo *root, Node *node) { max_parallel_hazard_context context; - /* If max_parallel_hazard found nothing unsafe, we don't need to look */ - if (root->glob->maxParallelHazard == PROPARALLEL_SAFE) + /* + * Even if the original querytree contained nothing unsafe, we need to + * search the expression if we have generated any PARAM_EXEC Params while + * planning, because those are parallel-restricted and there might be one + * in this expression. But otherwise we don't need to look. + */ + if (root->glob->maxParallelHazard == PROPARALLEL_SAFE && + root->glob->nParamExec == 0) return true; /* Else use max_parallel_hazard's search logic, but stop on RESTRICTED */ context.max_hazard = PROPARALLEL_SAFE;