Re: Concern about memory management with SRFs
От | Joe Conway |
---|---|
Тема | Re: Concern about memory management with SRFs |
Дата | |
Msg-id | 3D6D76BA.80600@joeconway.com обсуждение исходный текст |
Ответ на | Concern about memory management with SRFs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Concern about memory management with SRFs
|
Список | pgsql-hackers |
Tom Lane wrote: > I think we should document that any memory that is allocated in the > first call for use in subsequent calls must come from the memory context > saved in FuncCallContext (and let's choose a more meaningful name than > fmctx, please). This would mean adding code like > > oldcontext = MemoryContextSwitchTo(funcctx->fmctx); > > ... > > MemoryContextSwitchTo(oldcontext); > > around the setup code that follows SRF_FIRSTCALL_INIT. Then it would be > safe for nodeFunctionscan.c to do a reset before each function call. That sounds like a good plan. But can/should we wrap those calls in either existing or new macros? Or is it better to have the function author keenly aware of the memory management details? I tend to think the former is better. Maybe SRF_FIRSTCALL_INIT()(init_MultiFuncCall()) should: - save CurrentMemoryContext to funcctx->per_call_memory_ctx (new member of the struct) - save fcinfo->flinfo->fn_mcxt to funcctx->multi_call_memory_ctx (nee funcctx->fmctx) - leave fcinfo->flinfo->fn_mcxt as the current memory context when it exits Then SRF_PERCALL_SETUP() (per_MultiFuncCall()) can change back to funcctx->per_call_memory_ctx. Would this work? Joe
В списке pgsql-hackers по дате отправления: