Fix failure due to accessing an already-freed tuple descriptor in a plan

involving HashAggregate over SubqueryScan (this is the known case, there
may well be more).  The bug is only latent in releases before 8.2 since they
didn't try to access tupletable slots' descriptors during ExecDropTupleTable.
The least bogus fix seems to be to make subqueries share the parent query's
memory context, so that tupdescs they create will have the same lifespan as
those of the parent query.  There are comments in the code envisioning going
even further by not having a separate child EState at all, but that will
require rethinking executor access to range tables, which I don't want to
tackle right now.  Per bug report from Jean-Pierre Pelletier.

1 files changed, 5 insertions, 14 deletions

diff --git a/src/backend/executor/nodeSubplan.c b/src/backend/executor/nodeSubplan.c
index 2a5fd6d955d..069b5b7aa22 100644
--- a/src/backend/executor/nodeSubplan.c
+++ b/src/backend/executor/nodeSubplan.c
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1994, Regents of the University of California
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/nodeSubplan.c,v 1.80 2006/10/04 00:29:53 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/nodeSubplan.c,v 1.81 2006/12/26 21:37:19 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -635,7 +635,6 @@ ExecInitSubPlan(SubPlanState *node, EState *estate, int eflags)
 {
 	SubPlan    *subplan = (SubPlan *) node->xprstate.expr;
 	EState	   *sp_estate;
-	MemoryContext oldcontext;
 
 	/*
 	 * Do access checking on the rangetable entries in the subquery.
@@ -661,15 +660,13 @@ ExecInitSubPlan(SubPlanState *node, EState *estate, int eflags)
 	 * create an EState for the subplan
 	 *
 	 * The subquery needs its own EState because it has its own rangetable. It
-	 * shares our Param ID space, however.	XXX if rangetable access were done
-	 * differently, the subquery could share our EState, which would eliminate
-	 * some thrashing about in this module...
+	 * shares our Param ID space and es_query_cxt, however.  XXX if rangetable
+	 * access were done differently, the subquery could share our EState,
+	 * which would eliminate some thrashing about in this module...
 	 */
-	sp_estate = CreateExecutorState();
+	sp_estate = CreateSubExecutorState(estate);
 	node->sub_estate = sp_estate;
 
-	oldcontext = MemoryContextSwitchTo(sp_estate->es_query_cxt);
-
 	sp_estate->es_range_table = subplan->rtable;
 	sp_estate->es_param_list_info = estate->es_param_list_info;
 	sp_estate->es_param_exec_vals = estate->es_param_exec_vals;
@@ -694,8 +691,6 @@ ExecInitSubPlan(SubPlanState *node, EState *estate, int eflags)
 
 	node->needShutdown = true;	/* now we need to shutdown the subplan */
 
-	MemoryContextSwitchTo(oldcontext);
-
 	/*
 	 * If this plan is un-correlated or undirect correlated one and want to
 	 * set params for parent plan then mark parameters as needing evaluation.
@@ -1036,11 +1031,7 @@ ExecEndSubPlan(SubPlanState *node)
 {
 	if (node->needShutdown)
 	{
-		MemoryContext oldcontext;
-
-		oldcontext = MemoryContextSwitchTo(node->sub_estate->es_query_cxt);
 		ExecEndPlan(node->planstate, node->sub_estate);
-		MemoryContextSwitchTo(oldcontext);
 		FreeExecutorState(node->sub_estate);
 		node->sub_estate = NULL;
 		node->planstate = NULL;