mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-27 08:39:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

Ensure that the result tuple of an EvalPlanQual cycle gets materialized

Browse Source 
before we zap the input tuple.  Otherwise, pass-by-reference columns of
the result slot are likely to contain just references to the input
tuple, leading to big trouble if the pfree'd space is reused.  Per
trouble report from Jaime Casanova.  This is a new bug in the recent
rewrite of EvalPlanQual, so nothing to back-patch.
This commit is contained in:
Tom Lane 2009-12-11 18:14:43 +00:00
parent f1325ce213
commit d8e511fabb
1 changed files with 11 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/executor/execMain.c
View File

@ -26,7 +26,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.336 2009/12/09 21:57:51 tgl Exp $
* $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.337 2009/12/11 18:14:43 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -1407,6 +1407,16 @@ EvalPlanQual(EState *estate, EPQState *epqstate,
*/
slot = EvalPlanQualNext(epqstate);
/*
* If we got a tuple, force the slot to materialize the tuple so that
* it is not dependent on any local state in the EPQ query (in particular,
* it's highly likely that the slot contains references to any pass-by-ref
* datums that may be present in copyTuple). As with the next step,
* this is to guard against early re-use of the EPQ query.
*/
if (!TupIsNull(slot))
(void) ExecMaterializeSlot(slot);
/*
* Clear out the test tuple. This is needed in case the EPQ query
* is re-used to test a tuple for a different relation. (Not clear