On 2017-10-06 15:37:03 -0400, Tom Lane wrote:
> So a leak would occur in any case ... but it's particularly awful in
> this case, because data->'id' involves detoasting the rather wide
> value of "data", which is then promptly leaked.
While not tackling the problem in a systematic manner, it seems like
it'd be a good idea to free the detoasted column in this and related
functions?
> As of v10, it might be possible to fix this for the tlist case
> as well, by doing something like using a separate short-lived
> context for the non-SRF tlist items.
Yea, that should be quite doable, slightly annoying to need more than
one expr context, but that seems unavoidable. Should even be doable for
SFRM_ValuePerCall? SFRM_Materialize isn't a "central" problem, given it
properly manages memory for the tuplestore and filling the tuplestore is
an internal matter.
Greetings,
Andres Freund
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs