Re: Should I free this memory?

On Sat, Apr 23, 2011 at 5:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?ISO-8859-1?Q?Jorge_Ar=E9valo?= <jorge(dot)arevalo(at)deimos-space(dot)com> writes:
>> old_context = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt);
>> p = palloc(100);
>> MemoryContextSwitchTo(old_context);
>
> Why are you doing that?
>

It's a simplified example. The point is some memory is allocated in
that context and is not free'd. I'm trying to understand it. Not my
code.

>> Should I free the memory allocated for p? I'm getting memory leaks
>> when I don't free the memory, and they disappear when I call pfree(p);
>
> If you allocate that space again on every call, yes you'll get leaks.
> The fn_mcxt context typically has query lifespan, and could be even
> longer lived than that.
>
> While you could fix it with a pfree at the end of the function, you'll
> still have a leak if you lose control partway through due to some
> function throwing an elog(ERROR).  By and large, if you intend to
> allocate the space again on every call anyway, you should just palloc it
> in your calling memory context, which has got tuple-cycle lifespan and
> so doesn't pose much risk of bloat.  The only reason to allocate
> something in fn_mcxt is if you're trying to cache data across successive
> function calls.
>

Interesting. I've read the README document at src/backend/utils/mmgr,
and I have some unclear points yet:

I've understood several well-known memory contexts exist
(TopMemoryContext, CacheMemoryContext, MessageContext,
CurTransactionContext...), but I don't know what memory context are
more important for the creator of a new SQL function. It's really
important for me, because I'm extending my PostgreSQL server (version
8.4.7) with my own functions.

For example, I know every time a SQL function is called, a new memory
context is created (son of MessageMemoryContex, PortalContext,
CurTransactionContext?). Every chunk of memory allocated here by
palloc/repalloc is automatically free'd at the end of the function.
Apart from this "normal" memory context, I've identified two more
contexts:

- The one pointed by fcinfo->flinfo->fn_mcxt. It has query-cycle
persistence, you said.
- The one pointed by funcctx->multi_call_memory_ctx, in SRF. With
query-cycle persistence too, I suppose.

What's the difference between both? Reading the definition of FmgrInfo
struct at http://doxygen.postgresql.org/fmgr_8h-source.html#l00044, I
understand fn_mcxt is the memory context where the data pointed my
fn_extra is stored, it has query-cycle lifespan and must be managed by
the user (I should free'd everything). And multi_call_memory_ctx "is
the most appropriate memory context for any memory that is to be
reused across multiple calls of the SRF". But I don't know when and
where I should use them.

And another question: what's the difference between tuple-cycle and
query-cycle lifespan? In case of functions returning several rows
(SRF), I see it clear. But in case of functions returning single
values, or single rows, I can't see it.

>                        regards, tom lane
>

Many thanks for your response, and sorry for bothering you with so
many questions.

Best regards,

--
Jorge Arévalo
Internet & Mobilty Division, DEIMOS
jorge(dot)arevalo(at)deimos-space(dot)com
http://es.linkedin.com/in/jorgearevalo80
http://mobility.grupodeimos.com/
http://gis4free.wordpress.com
http://geohash.org/ezjqgrgzz0g