On Mon, Mar 20, 2006 at 12:36:58PM +0100, Thomas Hallgren wrote:
> The function in question uses the SRF_ family of macros. I'm always
> returning datums allocated in the context that was current when the
> function was callled.
>
> But, hrrm. I see that I use the durable 'multi_call_memory_ctx'
> throughout the whole procedure. I set it up during SRF_IS_FIRSTCALL()
> and then I reinstate it for the duration of each call, in effect
> preserving every temporary allocation that is made until the set is
> completely returned. Oops! That would account for one of the contexts
> being filled up, but not both. Exactly what is stored in the
> 'ExecutorState' and the 'SPI Proc' contexts? What is their life-cycle?
Hmm, without seeing the code it's hard to tell. However, many functions
expect to be called from short-lived contexts and tend to leak small
amounts of memory. If you're allocating everything into a long-lived
context, it's possible these little allocations are getting you.
Consider the string btree comparison function. Normally it could be
sloppy about how it allocates memory, but when PostgreSQL does a CREATE
INDEX, it calls that function a *lot* without any intervening context
reset, causing memory issues. So that particular is coded carefully to
avoid this.
SPI Proc is the context allocated for that procedure, it's is never
reset explicitly AFAICS. SPI calls execute in another context which is
reset regularly. ExecutorState is the tag given to all exec nodes, not
sure how to find out exactly what it's for.
Not sure what else to say. Perhaps tracing the context each allocation
is done in might help.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.