From a25726eae584bf56d3ddcf984bc1b54765088492 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 14 Jul 2009 15:37:50 +0000 Subject: [PATCH] Do a conditional SPI_push/SPI_pop when replanning a query in RevalidateCachedPlan. This is to avoid a "SPI_ERROR_CONNECT" failure when the planner calls a SPI-using function and we are already inside one. The alternative fix is to expect callers of RevalidateCachedPlan to do this, which seems likely to result in additional hard-to-detect bugs of omission. Per reports from Frank van Vugt and Marek Lewczuk. Back-patch to 8.3. It's much harder to trigger the bug in 8.3, due to a smaller set of cases in which plans can be invalidated, but it could happen. (I think perhaps only a SI reset event could make 8.3 fail here, but that's certainly within the realm of possibility.) --- src/backend/utils/cache/plancache.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/backend/utils/cache/plancache.c b/src/backend/utils/cache/plancache.c index a400dbff22..8fc2d5ad1d 100644 --- a/src/backend/utils/cache/plancache.c +++ b/src/backend/utils/cache/plancache.c @@ -45,6 +45,7 @@ #include "access/transam.h" #include "catalog/namespace.h" #include "executor/executor.h" +#include "executor/spi.h" #include "nodes/nodeFuncs.h" #include "optimizer/planmain.h" #include "storage/lmgr.h" @@ -502,8 +503,19 @@ RevalidateCachedPlan(CachedPlanSource *plansource, bool useResOwner) { /* * Generate plans for queries. + * + * The planner may try to call SPI-using functions, which causes + * a problem if we're already inside one. Rather than expect + * all SPI-using code to do SPI_push whenever a replan could + * happen, it seems best to take care of the case here. */ + bool pushed; + + pushed = SPI_push_conditional(); + slist = pg_plan_queries(slist, plansource->cursor_options, NULL); + + SPI_pop_conditional(pushed); } /* -- 2.39.5