Andres Freund <andres@anarazel.de> writes:
> 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?
I think that's basically a dead-end solution. It amounts to saying
that no functions can leak memory, which is not a place we're ever
likely to get to, especially given that there's been no policy
favoring that in the past (with the narrow exception of btree
comparison 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.
I'm not really convinced whether there's an issue for ValuePerCall SRFs.
We've not had complaints about them, and I would think we would if that
feature alone would create an issue. But I've not thought about it hard,
nor tested.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
