On Thu, Apr 8, 2010 at 6:18 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Thu, Apr 8, 2010 at 11:40 AM, Jorge Arevalo > <jorgearev...@gis4free.org> wrote: >> Is this a good way of doing it? Is it possible? And another small >> question: if the memory for my array of structs is allocated inside >> the function that provides me the array, should I deallocate it in the >> SRF? Using pfree? It wasn't allocated by palloc... > > why didn't you use palloc? external library? postgresql guarantees > that memory allocated w/palloc is cleaned up. you pretty much have to > assume any backend api calls can bounce you out of the transaction in > which case you will leak if you alloc'd with non palloc allocator. do > not call pfree on any memory allocated by anything else than palloc. > every malloc needs a free. > > if the array construction code is also yours you may want to consider > reworking it to take an allocator. the more you use palloc the less > problems you will have (and as a bonus, you get to worry less about > pfree'ing stuff). > > if you must use malloc and don't want to be cavalier about leaking > memory, try and keep allocations as short lived as possible or at very > specific points, like a static pointer. >
The memory is allocated in a function of an external library. But I can force this library to allocate memory in a valid context (the one pointed by fcinfo->flinfo->fn_mcxt, actually). If I do that, I suppose I can call pfree. Or even better, I don't need to worry about that, am I right? BTW, this code is for WKT Raster. A PostGIS extension. We can use the memory context I said (fcinfo->flinfo->fn_mcxt) to allocate memory when we need to call one of our functions from a standard "version 1" function, but is this the right context? I mean, the context we should use for a whole-plugin-lifetime persistence. > be sure to review the memory manager readme in src/backend/utils/mmgr/README > Excelent reading! Thanks for the info. And sorry if my questions are very basic. Best regards, Jorge > merlin > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
