From d8e511fabbff0554cb872186c8a5de3b7715ec9b Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 11 Dec 2009 18:14:43 +0000 Subject: [PATCH] Ensure that the result tuple of an EvalPlanQual cycle gets materialized 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. --- src/backend/executor/execMain.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index 9d7bdb777c..ebb6d8ea82 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.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 $ * *------------------------------------------------------------------------- */ @@ -1408,6 +1408,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 * that can really happen, but let's be safe.) -- 2.11.0