Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
