On Mon, Jul 22, 2013 at 10:02:30PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Sun, Jul 21, 2013 at 12:40:38PM -0400, Tom Lane wrote:
> >> Hmm ... good point. The other plan I'd been considering was to add
> >> explicit tracking inside spi.c of all tuple tables created within the
> >> current procedure, and then have AtEOSubXact_SPI flush any that were
> >> created inside a failed subxact.
>
> > Is there reason to believe we wouldn't eventually find a half dozen other
> > allocations calling for similar bespoke treatment? Does something make tuple
> > tables special among memory allocations, or are they just the garden-variety
> > allocation that happens to bother the test case at hand?
>
> It's hard to speculate about the memory management habits of third-party
> SPI-using code. But in plpgsql, the convention is that random bits of
> memory should be allocated in a short-term context separate from the SPI
> procCxt --- typically, the estate->eval_econtext expression context,
> which exec_stmt_block already takes care to clean up when catching an
> exception. So the problem is that that doesn't work for tuple tables,
> which have procCxt lifespan. The fact that they tend to be big (at
> least 8K apiece) compounds the issue.
Reasonable to treat them specially, per your plan, then.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com