Re: Concern about memory management with SRFs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Concern about memory management with SRFs
Date: 2002-08-29 01:32:09
Message-ID: 6481.1030584729@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-08-29 01:46:55 Re: Concern about memory management with SRFs
Previous Message Joe Conway 2002-08-29 01:19:54 Re: Concern about memory management with SRFs

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2002-08-29 01:46:55 Re: Concern about memory management with SRFs
Previous Message Tom Lane 2002-08-29 01:21:09 Re: Anonymous-record-types omission