From 4a1bffa066e46a5707db33f5c8403df74c00e322 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 26 Dec 2006 21:37:28 +0000 Subject: 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. --- src/backend/executor/execMain.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'src/backend/executor/execMain.c') diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index 5e5ca085ba4..1d6284c357c 100644 --- a/src/backend/executor/execMain.c +++ b/src/backend/executor/execMain.c @@ -26,7 +26,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.280 2006/10/04 00:29:52 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.280.2.1 2006/12/26 21:37:28 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -2223,6 +2223,10 @@ EvalPlanQualStart(evalPlanQual *epq, EState *estate, evalPlanQual *priorepq) rtsize = list_length(estate->es_range_table); + /* + * It's tempting to think about using CreateSubExecutorState here, but + * at present we can't because of memory leakage concerns ... + */ epq->estate = epqstate = CreateExecutorState(); oldcontext = MemoryContextSwitchTo(epqstate->es_query_cxt); -- cgit v1.2.3