diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2000-08-22 04:06:22 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2000-08-22 04:06:22 +0000 |
| commit | 0147b1934f251183d3614bca011bf21205890835 (patch) | |
| tree | ed7df11ba0ecbdae22095a2eeacbd204dcdca1b8 /src/backend/executor/execUtils.c | |
| parent | 94e90d9a86a186c83891fe4ce3e343bcf1860053 (diff) | |
| download | postgresql-0147b1934f251183d3614bca011bf21205890835.tar.gz postgresql-0147b1934f251183d3614bca011bf21205890835.zip | |
Fix a many-legged critter reported by chifungfan@yahoo.com: under the
right circumstances a hash join executed as a DECLARE CURSOR/FETCH
query would crash the backend. Problem as seen in current sources was
that the hash tables were stored in a context that was a child of
TransactionCommandContext, which got zapped at completion of the FETCH
command --- but cursor cleanup executed at COMMIT expected the tables
to still be valid. I haven't chased down the details as seen in 7.0.*
but I'm sure it's the same general problem.
Diffstat (limited to 'src/backend/executor/execUtils.c')
| -rw-r--r-- | src/backend/executor/execUtils.c | 35 |
1 files changed, 22 insertions, 13 deletions
diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c index 39e3d5cd48b..63c1e9e157f 100644 --- a/src/backend/executor/execUtils.c +++ b/src/backend/executor/execUtils.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/backend/executor/execUtils.c,v 1.64 2000/07/14 22:17:45 tgl Exp $ + * $Header: /cvsroot/pgsql/src/backend/executor/execUtils.c,v 1.65 2000/08/22 04:06:19 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -866,9 +866,8 @@ ExecInsertIndexTuples(TupleTableSlot *slot, heapTuple = slot->val; - /* ---------------- - * get information from the result relation info structure. - * ---------------- + /* + * Get information from the result relation info structure. */ resultRelationInfo = estate->es_result_relation_info; numIndices = resultRelationInfo->ri_NumIndices; @@ -877,14 +876,26 @@ ExecInsertIndexTuples(TupleTableSlot *slot, heapRelation = resultRelationInfo->ri_RelationDesc; heapDescriptor = RelationGetDescr(heapRelation); - /* ---------------- - * Make a temporary expr/memory context for evaluating predicates - * and functional-index functions. - * XXX should do this once per command not once per tuple, and - * just reset it once per tuple. - * ---------------- + /* + * We will use the EState's per-tuple context for evaluating predicates + * and functional-index functions. Create it if it's not already there; + * if it is, reset it to free previously-used storage. */ - econtext = MakeExprContext(slot, TransactionCommandContext); + econtext = estate->es_per_tuple_exprcontext; + if (econtext == NULL) + { + MemoryContext oldContext; + + oldContext = MemoryContextSwitchTo(estate->es_query_cxt); + estate->es_per_tuple_exprcontext = econtext = + MakeExprContext(NULL, estate->es_query_cxt); + MemoryContextSwitchTo(oldContext); + } + else + ResetExprContext(econtext); + + /* Arrange for econtext's scan tuple to be the tuple under test */ + econtext->ecxt_scantuple = slot; /* ---------------- * for each index, form and insert the index tuple @@ -935,8 +946,6 @@ ExecInsertIndexTuples(TupleTableSlot *slot, if (result) pfree(result); } - - FreeExprContext(econtext); } void |