summaryrefslogtreecommitdiff
path: root/src/include/executor/spi.h
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-07-25 16:45:43 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2013-07-25 16:46:14 -0400
commit3d13623d75d3206c8f009353415043a191ebab39 (patch)
tree68a6e48fe6dfc7aac44b1e039c2a2f965d2ac4ec /src/include/executor/spi.h
parentfd27b999196959bd20d777a1010c786feb1586c2 (diff)
downloadpostgresql-3d13623d75d3206c8f009353415043a191ebab39.tar.gz
Prevent leakage of SPI tuple tables during subtransaction abort.
plpgsql often just remembers SPI-result tuple tables in local variables, and has no mechanism for freeing them if an ereport(ERROR) causes an escape out of the execution function whose local variable it is. In the original coding, that wasn't a problem because the tuple table would be cleaned up when the function's SPI context went away during transaction abort. However, once plpgsql grew the ability to trap exceptions, repeated trapping of errors within a function could result in significant intra-function-call memory leakage, as illustrated in bug #8279 from Chad Wagner. We could fix this locally in plpgsql with a bunch of PG_TRY/PG_CATCH coding, but that would be tedious, probably slow, and prone to bugs of omission; moreover it would do nothing for similar risks elsewhere. What seems like a better plan is to make SPI itself responsible for freeing tuple tables at subtransaction abort. This patch attacks the problem that way, keeping a list of live tuple tables within each SPI function context. Currently, such freeing is automatic for tuple tables made within the failed subtransaction. We might later add a SPI call to mark a tuple table as not to be freed this way, allowing callers to opt out; but until someone exhibits a clear use-case for such behavior, it doesn't seem worth bothering. A very useful side-effect of this change is that SPI_freetuptable() can now defend itself against bad calls, such as duplicate free requests; this should make things more robust in many places. (In particular, this reduces the risks involved if a third-party extension contains now-redundant SPI_freetuptable() calls in error cleanup code.) Even though the leakage problem is of long standing, it seems imprudent to back-patch this into stable branches, since it does represent an API semantics change for SPI users. We'll patch this in 9.3, but live with the leakage in older branches.
Diffstat (limited to 'src/include/executor/spi.h')
-rw-r--r--src/include/executor/spi.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/src/include/executor/spi.h b/src/include/executor/spi.h
index d4f1272cd8..81310e377f 100644
--- a/src/include/executor/spi.h
+++ b/src/include/executor/spi.h
@@ -13,6 +13,7 @@
#ifndef SPI_H
#define SPI_H
+#include "lib/ilist.h"
#include "nodes/parsenodes.h"
#include "utils/portal.h"
@@ -24,6 +25,8 @@ typedef struct SPITupleTable
uint32 free; /* # of free vals */
TupleDesc tupdesc; /* tuple descriptor */
HeapTuple *vals; /* tuples */
+ slist_node next; /* link for internal bookkeeping */
+ SubTransactionId subid; /* subxact in which tuptable was created */
} SPITupleTable;
/* Plans are opaque structs for standard users of SPI */