Re: [BUGS] BUG #8573: int4range memory consumption

On 2013-11-02 15:29:36 -0400, Tom Lane wrote:
> Attached is a proposed patch for this. It fixes most of the functions
> in printtup.c to use a per-row memory context. (I did not bother to
> fix debugtup(), which is used only in standalone mode. If you're doing
> queries large enough for mem leaks to be problematic in standalone mode,
> you're nuts.)

FWIW, by that definition I have been nuts several time in the past -
without much choice since I was recovering data from a corrupted cluster
and the database couldn't be started normally. This now has gotten worse
(even in the backbranches) since debugtup won't clean up detoasted data
anymore.
But I guess the solution for that is to use COPY in those situations
which shouldn't have that problem and should work. Also, easier to parse ;)

> My original thought had been to get rid of all pfree's of output function
> results, so as to make the world safe for returning constant strings when
> such functions find it appropriate. However, I ran into a showstopper
> problem: SPI_getvalue(), which is little more than a wrapper around the
> appropriate type output function, is documented as returning a pfree'able
> string. Some though not all of the callers in core and contrib take the
> hint and pfree the result, and I'm sure there are more in third-party
> extensions. So if we want to allow output functions to return
> non-palloc'd strings, it seems we have to either change SPI_getvalue()'s
> API contract or insert a pstrdup() call in it. Neither of these is
> attractive, mainly because the vast majority of output function results
> would still be palloc'd even if we made aggressive use of the option not
> to. That means that if we did the former, light testing wouldn't
> necessarily show a problem if someone forgot to remove a pfree() after a
> SPI_getvalue() call, and it also means that if we did the latter, the
> pstrdup() would usually be a waste of cycles and space.

I guess one option for the future is to to pstrdup() in SPI_getvalue()
and adding a new function that tells whether the result can be freed or
not. Then callers that care can move over. Although I'd guess that many
of those caring will already use SPI_getbinval() manually.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services