Plug leak in BuildTupleHashTable by creating ExprContext in correct context.

anarazel · anarazel · commit 5567d12ce030 · 2019-02-09T01:05:49.000-08:00
In bf6c614 I added a expr context to evaluate the grouping expression. Unfortunately the code I added initialized them while in the calling context, rather the table context. Additionally, I used CreateExprContext() rather than CreateStandaloneExprContext(), which creates the econtext in the estate's query context. Fix that by using CreateStandaloneExprContext when in the table's tablecxt. As we rely on the memory being freed by a memory context reset that means that the econtext's shutdown callbacks aren't being called, but that seems ok as the expressions are tightly controlled due to ExecBuildGroupingEqual(). Bug: #15592 Reported-By: Dmitry Marakasov Author: Andres Freund Discussion: https://postgr.es/m/20190114222838.h6r3fuyxjxkykf6t@alap3.anarazel.de Backpatch: 11, where I broke this in bf6c614
diff --git a/src/backend/executor/execGrouping.c b/src/backend/executor/execGrouping.c
@@ -212,11 +212,17 @@ BuildTupleHashTable(PlanState *parent,
 													&TTSOpsMinimalTuple, &TTSOpsMinimalTuple,
 													numCols,
 													keyColIdx, eqfuncoids,
-													parent);
+													NULL);
 
-	MemoryContextSwitchTo(oldcontext);
+	/*
+	 * While not pretty, it's ok to not shut down this context, but instead
+	 * rely on the containing memory context being reset, as
+	 * ExecBuildGroupingEqual() only builds a very simple expression calling
+	 * functions (i.e. nothing that'd employ RegisterExprContextCallback()).
+	 */
+	hashtable->exprcontext = CreateStandaloneExprContext();
 
-	hashtable->exprcontext = CreateExprContext(parent->state);
+	MemoryContextSwitchTo(oldcontext);
 
 	return hashtable;
 }
