On Mon, Jul 22, 2013 at 10:02:30PM -0400, Tom Lane wrote: > Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
