Thread: C-language functions: SRF question
Hello, I need to code a set-returning function, but it's my first time, and I'm not sure if my point is the right one. I'd like to know your opinion: My function will return an array of structs. Then, In the first call (SRF_IS_FIRSTCALL() is true), I get the array from another function. For the next calls, I'll need to access a position of this array, so, I'll need to store it, and the position needed, in any place. The place should be the user_fctx field of the FuncCallContext. I've created a struct that will store my array of structs and an int value, a index. In the first call, this index is 0. In next calls, I can recover data from FuncCallContext, get the struct indexed by the index value, build my tuple, return it and increment the index. 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... Thanks in advance, and best regards, Jorge -- http://www.gis4free.org/blog
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
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 >
Jorge Arevalo <jorgearevalo@gis4free.org> writes: > 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. fn_mcxt will typically point at a query-lifespan context. If you need to allocate storage that will live as long as the session, there's not that much reason not to use malloc, except perhaps that you have to remember to do your own out-of-memory-failure checks. The typical coding pattern in the backend for session-lifespan storage is to use TopMemoryContext, or possibly make your own context (as a child of TopMemoryContext) so that you can easily identify how much storage you're using for this purpose. regards, tom lane