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

Commit d7885b1

Browse files
committed
Build EC members for child join rels in the right memory context.
This patch prevents crashes or wrong plans when partition-wise joins are considered during GEQO planning, as a consequence of the EquivalenceClass data structures becoming corrupt after a GEQO context reset. A remaining problem is that successive GEQO cycles will make multiple copies of the required EC members, since add_child_join_rel_equivalences has no idea that such members might exist already. For now we'll just live with that. The lack of field complaints of crashes suggests that this is a mighty little-used situation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/1683100.1601860653@sss.pgh.pa.us
1 parent 1b22224 commit d7885b1

File tree

1 file changed

+13
-0
lines changed

1 file changed

+13
-0
lines changed

src/backend/optimizer/path/equivclass.c

+13
Original file line numberDiff line numberDiff line change
@@ -2380,13 +2380,24 @@ add_child_join_rel_equivalences(PlannerInfo *root,
23802380
Relids top_parent_relids = child_joinrel->top_parent_relids;
23812381
Relids child_relids = child_joinrel->relids;
23822382
Bitmapset *matching_ecs;
2383+
MemoryContext oldcontext;
23832384
int i;
23842385

23852386
Assert(IS_JOIN_REL(child_joinrel) && IS_JOIN_REL(parent_joinrel));
23862387

23872388
/* We need consider only ECs that mention the parent joinrel */
23882389
matching_ecs = get_eclass_indexes_for_relids(root, top_parent_relids);
23892390

2391+
/*
2392+
* If we're being called during GEQO join planning, we still have to
2393+
* create any new EC members in the main planner context, to avoid having
2394+
* a corrupt EC data structure after the GEQO context is reset. This is
2395+
* problematic since we'll leak memory across repeated GEQO cycles. For
2396+
* now, though, bloat is better than crash. If it becomes a real issue
2397+
* we'll have to do something to avoid generating duplicate EC members.
2398+
*/
2399+
oldcontext = MemoryContextSwitchTo(root->planner_cxt);
2400+
23902401
i = -1;
23912402
while ((i = bms_next_member(matching_ecs, i)) >= 0)
23922403
{
@@ -2486,6 +2497,8 @@ add_child_join_rel_equivalences(PlannerInfo *root,
24862497
}
24872498
}
24882499
}
2500+
2501+
MemoryContextSwitchTo(oldcontext);
24892502
}
24902503

24912504

0 commit comments

Comments
 (0)