Repair bug that allowed RevalidateCachedPlan to attempt to rebuild a cached

plan before the effects of DDL executed in an immediately prior SPI operation
had been absorbed.  Per report from Chris Wood.

This patch has an unpleasant side effect of causing the number of
CommandCounterIncrement()s done by a typical plpgsql function to
approximately double.  Amelioration of the consequences of that
will be undertaken in a separate patch.

src/backend/executor/spi.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/spi.c,v 1.184 2007/11/15 21:14:35 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/spi.c,v 1.185 2007/11/30 18:38:34 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1374,14 +1374,6 @@ _SPI_prepare_plan(const char *src, SPIPlanPtr plan)
 	int			nargs = plan->nargs;
 	int			cursor_options = plan->cursor_options;
 
-	/*
-	 * Increment CommandCounter to see changes made by now.  We must do this
-	 * to be sure of seeing any schema changes made by a just-preceding SPI
-	 * command.  (But we don't bother advancing the snapshot, since the
-	 * planner generally operates under SnapshotNow rules anyway.)
-	 */
-	CommandCounterIncrement();
-
 	/*
 	 * Setup error traceback support for ereport()
 	 */
@@ -1662,6 +1654,14 @@ _SPI_execute_plan(SPIPlanPtr plan, Datum *Values, const char *Nulls,
 			if (cplan)
 				ReleaseCachedPlan(cplan, true);
 			cplan = NULL;
+
+			/*
+			 * If not read-only mode, advance the command counter after the
+			 * last command.  This ensures that its effects are visible, in
+			 * case it was DDL that would affect the next CachedPlanSource.
+			 */
+			if (!read_only)
+				CommandCounterIncrement();
 		}
 
 fail: