On 2017-10-06 19:42:05 -0700, Andres Freund wrote:
> On 2017-10-06 22:35:37 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > I've just played around with this. ValuePerCall SRFs are fine with
> > > called in a short-lived context (they're required to be able to, as
> > > documented in xfunc.sgml), so is SFRM_Materialize. The only thing to be
> > > careful about is the *arguments* to the function, those need to live
> > > long enough in the ValuePerCall case.
> >
> > Isn't there already code to deal with that? See around line 175
> > in execSRF.c.
>
> Well, that's for nodeFunctionscan.c, not nodeProjectSet.c. But it seems
> quite sensible to model this very similarly.
Patch attached. The business with having to switch the memory context
tuplestore_gettupleslot() ain't pretty, but imo is tolerable.
I'm kinda tempted to put this, after a bit more testing, into v10.
After this Lucas' testcase doesn't leak memory anymore - it's still slow
in execution, decompressing the same datum over and over. But that feels
like something that should be fixed separately.
- Andres
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs