Re: Concern about memory management with SRFs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Concern about memory management with SRFs
Date
Msg-id 6481.1030584729@sss.pgh.pa.us
Whole thread Raw
In response to Re: Concern about memory management with SRFs  (Joe Conway <mail@joeconway.com>)
List 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 by date:

Previous
From: Joe Conway
Date:
Subject: Re: Concern about memory management with SRFs
Next
From: Joe Conway
Date:
Subject: Re: Concern about memory management with SRFs