Re: Recursive calls to functions that return sets

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Thomas Hallgren <thomas(at)tada(dot)se>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recursive calls to functions that return sets
Date: 2006-03-22 20:21:32
Message-ID: 20060322202132.GF29954@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 22, 2006 at 09:09:34PM +0100, Thomas Hallgren wrote:
> 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?

Ok, I'm not sure if I understand the reasoning but I think it's like
this:

- When the results of an SRF are accumulated by
ExecMakeTableFunctionResult, that function is reseting your context
each time.

- When you call SPI_connect it creates a new context and switches to
it. It switches back on SPI_finish. SPI_finish switches to the context
active at SPI_connect, maybe this is not what you expect?

The ExecMakeTableFunctionResult only resets the one context, the one
provided when your function starts, anything created in other contexts
is Somebody Else's Problem. So the question, which context are you
allocating in?

Hope this clarifies it,
>

--
Martijn van Oosterhout <kleptog(at)svana(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2006-03-22 20:41:46 Accessing schema data in information schema
Previous Message Thomas Hallgren 2006-03-22 20:09:34 Re: Recursive calls to functions that return sets