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
This commit is contained in:
Tom Lane 2024-02-23 15:21:53 -05:00
parent d360e3cc60
commit a6b2a51e16
1 changed files with 7 additions and 2 deletions

View File

@ -1707,8 +1707,13 @@ create_unique_path(PlannerInfo *root, RelOptInfo *rel, Path *subpath,
pathnode->path.pathkeys = NIL;
pathnode->subpath = subpath;
pathnode->in_operators = sjinfo->semi_operators;
pathnode->uniq_exprs = sjinfo->semi_rhs_exprs;
/*
* Under GEQO, the sjinfo might be short-lived, so we'd better make copies
* of data structures we extract from it.
*/
pathnode->in_operators = copyObject(sjinfo->semi_operators);
pathnode->uniq_exprs = copyObject(sjinfo->semi_rhs_exprs);
/*
* If the input is a relation and it has a unique index that proves the