Build EC members for child join rels in the right memory context.

tglsfdc · tglsfdc · commit d7885b1f87fa · 2020-10-06T11:43:53.000-04:00
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
diff --git a/src/backend/optimizer/path/equivclass.c b/src/backend/optimizer/path/equivclass.c
@@ -2380,13 +2380,24 @@ add_child_join_rel_equivalences(PlannerInfo *root,
 	Relids		top_parent_relids = child_joinrel->top_parent_relids;
 	Relids		child_relids = child_joinrel->relids;
 	Bitmapset  *matching_ecs;
+	MemoryContext oldcontext;
 	int			i;
 
 	Assert(IS_JOIN_REL(child_joinrel) && IS_JOIN_REL(parent_joinrel));
 
 	/* We need consider only ECs that mention the parent joinrel */
 	matching_ecs = get_eclass_indexes_for_relids(root, top_parent_relids);
 
+	/*
+	 * If we're being called during GEQO join planning, we still have to
+	 * create any new EC members in the main planner context, to avoid having
+	 * a corrupt EC data structure after the GEQO context is reset.  This is
+	 * problematic since we'll leak memory across repeated GEQO cycles.  For
+	 * now, though, bloat is better than crash.  If it becomes a real issue
+	 * we'll have to do something to avoid generating duplicate EC members.
+	 */
+	oldcontext = MemoryContextSwitchTo(root->planner_cxt);
+
 	i = -1;
 	while ((i = bms_next_member(matching_ecs, i)) >= 0)
 	{
@@ -2486,6 +2497,8 @@ add_child_join_rel_equivalences(PlannerInfo *root,
 			}
 		}
 	}
+
+	MemoryContextSwitchTo(oldcontext);
 }
 
 

Original file line number	Diff line number	Diff line change
`@@ -2380,13 +2380,24 @@ add_child_join_rel_equivalences(PlannerInfo *root,`
`2380`	`2380`	`Relids top_parent_relids = child_joinrel->top_parent_relids;`
`2381`	`2381`	`Relids child_relids = child_joinrel->relids;`
`2382`	`2382`	`Bitmapset *matching_ecs;`
	`2383`	`+ MemoryContext oldcontext;`
`2383`	`2384`	`int i;`
`2384`	`2385`
`2385`	`2386`	`Assert(IS_JOIN_REL(child_joinrel) && IS_JOIN_REL(parent_joinrel));`
`2386`	`2387`
`2387`	`2388`	`/* We need consider only ECs that mention the parent joinrel */`
`2388`	`2389`	`matching_ecs = get_eclass_indexes_for_relids(root, top_parent_relids);`
`2389`	`2390`
	`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`	`+`
`2390`	`2401`	`i = -1;`
`2391`	`2402`	`while ((i = bms_next_member(matching_ecs, i)) >= 0)`
`2392`	`2403`	`{`
`@@ -2486,6 +2497,8 @@ add_child_join_rel_equivalences(PlannerInfo *root,`
`2486`	`2497`	`}`
`2487`	`2498`	`}`
`2488`	`2499`	`}`
	`2500`	`+`
	`2501`	`+ MemoryContextSwitchTo(oldcontext);`
`2489`	`2502`	`}`
`2490`	`2503`
`2491`	`2504`