On 2017-10-06 20:28:21 -0400, Tom Lane wrote:
> 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).
Hm. We've a bunch of places where we free detoasted data, just out of
efficiency concerns. And since the jsonb functions are quite likely to
detoast a lot, it doesn't seem unreasonable to do so for the most likely
offenders. I mean if you've a bit more complex expression involving a
few fields accessed, freeing in the accesses will reduce maximum memory
usage by quite a bit. I'm not suggesting to work towards leak free, just
towards reducing the lifetime of a few potentially large allocations.
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