database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-15 19:15:29 +03:00
Code

Fix optimization for skipping searches for parallel-query hazards.

Browse Source 
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>
This commit is contained in:
Tom Lane 2016-11-21 13:19:14 -05:00
parent a734fd5d1c
commit 4324ade9a6
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/optimizer/util/clauses.c
View File

@ -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;