Martijn van Oosterhout wrote:
> On Mon, Mar 20, 2006 at 11:47:41AM +0100, Thomas Hallgren wrote:
>
>> Hi,
>> A PL/Java user reports that his backend runs out of memory when he uses
>> PL/Java to execute huge queries towards a remote database and return the
>> result. PL/Java is designed not to collect data in memory when it
>> returns result sets. Each call to the function handler will be
>> dispatched to the corresponding 'ResultSet.next()' in order to retrieve
>> and propagate one row at a time. Yet, it seems the data is collected
>> somewhere. An excerpt from the user at the time he runs out of memory
>> looks like this:
>>
>
> It's not clear exactly what you are doing, but the Datum you return
> points to memory allocated *somewhere*. If you have palloc()ed it in
> your own MemoryContext then you must free it the next time you are
> called. Normally this is acheived by restting your context each time,
> although you could free if you wished.
>
> Hope this helps,
>
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?
Regards,
Thomas Hallgren