On Sat, Apr 23, 2011 at 5:11 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > =?ISO-8859-1?Q?Jorge_Ar=E9valo?= <jorge.arevalo@xxxxxxxxxxxxxxxx> 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.arevalo@xxxxxxxxxxxxxxxx http://es.linkedin.com/in/jorgearevalo80 http://mobility.grupodeimos.com/ http://gis4free.wordpress.com http://geohash.org/ezjqgrgzz0g -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
