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.
regards, tom lane
