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

Commit a6b2a51

Browse files
committed
Avoid dangling-pointer problem with partitionwise joins under GEQO.
build_child_join_sjinfo creates a derived SpecialJoinInfo in the short-lived GEQO context, but afterwards the semi_rhs_exprs from that may be used in a UniquePath for a child base relation. This breaks the expectation that all base-relation-level structures are in the planning-lifespan context, leading to use of a dangling pointer with probable ensuing crash later on in create_unique_plan. To fix, copy the expression trees when making a UniquePath. Per bug #18360 from Alexander Lakhin. This has been broken since partitionwise joins were added, so back-patch to all supported branches. Discussion: https://postgr.es/m/18360-a23caf3157f34e62@postgresql.org
1 parent d360e3c commit a6b2a51

File tree

1 file changed

+7
-2
lines changed

1 file changed

+7
-2
lines changed

src/backend/optimizer/util/pathnode.c

+7-2
Original file line numberDiff line numberDiff line change
@@ -1707,8 +1707,13 @@ create_unique_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
17071707
pathnode->path.pathkeys = NIL;
17081708

17091709
pathnode->subpath = subpath;
1710-
pathnode->in_operators = sjinfo->semi_operators;
1711-
pathnode->uniq_exprs = sjinfo->semi_rhs_exprs;
1710+
1711+
/*
1712+
* Under GEQO, the sjinfo might be short-lived, so we'd better make copies
1713+
* of data structures we extract from it.
1714+
*/
1715+
pathnode->in_operators = copyObject(sjinfo->semi_operators);
1716+
pathnode->uniq_exprs = copyObject(sjinfo->semi_rhs_exprs);
17121717

17131718
/*
17141719
* If the input is a relation and it has a unique index that proves the

0 commit comments

Comments
 (0)