On Thu, Apr 8, 2010 at 6:18 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Thu, Apr 8, 2010 at 11:40 AM, Jorge Arevalo
> <jorgearevalo@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
>