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.

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 9d7bdb777c5e99b471c7d8dd839a60f78d3fa61b..ebb6d8ea82c71a1246ab9adfda6be0653cd76813 100644 (file)
--- 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 $
  *
  *-------------------------------------------------------------------------
  */
@@ -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