Tom Lane wrote:
> Thomas Hallgren <thomas@tada.se> writes:
>
>> Recursive calls works in PL/Java. No problem there. But the larger the
>> set, the more memory it consumes. Do I read your answers correctly if I
>> conclude this is a known limitation when SPI is used? I.e. there's no
>> way to stream one row at a time without ever building the full set?
>>
>
> By no means. The point is that there are some callers of SRFs that are
> going to materialize the result set, as well as some SRFs that are going
> to hand back a materialized result set anyway. The interface can handle
> a tuple-per-call but that's not the way everybody chooses to use it.
>
>
OK. I've managed to get rid of my last memory-leak (i hope). I followed
Martijn's suggestion to create the returned tuple in my own context. Now
even the nastiest recursive chains using huge sets of data seems to
behave ok :-)
There's one thing that's still a bit fuzzy to me. If I don't use SPI,
the context that is current when my SRF function is called seems to be
reset between each call. I can palloc stuff in it as much as I like. I
can even create the tuple that I return using this context. No memory
leak. But if I, during the SPI_IS_FIRST_CALL phase, do an SPI_connect
(done when the 'multi_call_memory_ctx' is current), then the leak seem
to occur immediately. Will that connect somehow alter the durability for
the context that is current on each call to my SRF?
Regards,
Thomas Hallgren
