From: | Jorge Arévalo <jorge(dot)arevalo(at)deimos-space(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Should I free this memory? |
Date: | 2011-04-23 11:36:20 |
Message-ID: | BANLkTi=fSUWOmgL_hJ4GD1JXukc3NqH1Cw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Tolley | 2011-04-23 12:48:06 | Re: Cross-schema view issue/question |
Previous Message | Henry C. | 2011-04-23 11:22:23 | Re: 20110408pg_upgrade_fix and 'FATAL: could not access status of transaction...' |