postgres.git / summary / log / commit / refs

commit    4324ade9a6880113b08070305482ace2e8a2617c
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Mon Nov 21 18:19:14 2016 +0000

    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 1688310b805..9598f28bab3 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;


[parent: a734fd5d1c30]