Re: Concern about memory management with SRFs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Concern about memory management with SRFs
Дата
Msg-id 6481.1030584729@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Concern about memory management with SRFs  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> 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.

I thought about that and didn't like it; it may simplify the simple case
but I think it actively gets in the way of less-simple cases.  For
example, the FIRSTCALL code might generate some transient structures
along with ones that it wants to keep.  Also, your recommended
pseudocode allows the author to write code between the end of the
FIRSTCALL branch and the PERCALL_SETUP call; that code will not execute
in a predictable context if we do it this way.

I'm also not happy with the implied assumption that every call to the
function executes in the same transient context.  That is true at the
moment but I'd just as soon not see it as a wired-in assumption.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Concern about memory management with SRFs
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Concern about memory management with SRFs