Re: C-language functions: SRF question - Mailing list pgsql-general

From Merlin Moncure
Subject Re: C-language functions: SRF question
Date
Msg-id t2xb42b73151004080918neb05e9f7paa2b5a08b97c3935@mail.gmail.com
Whole thread Raw
In response to C-language functions: SRF question  (Jorge Arevalo <jorgearevalo@gis4free.org>)
Responses Re: C-language functions: SRF question
List pgsql-general
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.

be sure to review the memory manager readme in src/backend/utils/mmgr/README

merlin

pgsql-general by date:

Previous
From: Jorge Arevalo
Date:
Subject: C-language functions: SRF question
Next
From: Greg Stark
Date:
Subject: Re: Cannot read block 348938 of pdbsynchtable