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

Jim Nasby <decibel(at)decibel(dot)org> writes:
> On Nov 1, 2013, at 2:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> While we could doubtless hack range_out to release those strings again,
>> it seems to me that that's just sticking a finger in the dike. I'm
>> inclined to think that we really ought to solve this class of problems
>> once and for all by fixing printtup.c to run the output functions in a
>> temporary memory context,
>> ...
>> we're already using a reset-per-row approach to memory management of
>> output function calls in COPY OUT, and I know for a fact that we've
>> squeezed that code path as hard as we could.

> +1. COPY is actually the case I was worried about if you're dealing with large amounts of data in other clients ISTM that other things will bottleneck before the extra memory context.

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.) I also simplified some other places that had copied the
notion of forced detoasting before an output function call, as that seems
dubious at best, and wasn't being done uniformly anyway.

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.

So I've abandoned that idea for now, and just recommend applying the
attached patch as far back as 9.2, where range_out was added.

Comments?

regards, tom lane