Re: memory leak checking

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-22 20:29:17 -0400, Tom Lane wrote:
>> I would not call the timezone data a "leak", since it's still useful, and
>> accessible from static pointers, right up to exit. A true leak for this
>> purpose is memory that's allocated but not usefully accessible, and I'd
>> say we discourage that; though small one-time leaks may not be worth the
>> trouble to get rid of.

> Right. I was only referring to it that way because the various leak
> checking tools do, should've been more careful in wording...

FWIW, I just did a simple test with valgrind's --leak-check=full,
and I can't find any clear evidence of *any* real leaks in a normal
backend run. The things that valgrind thinks are leaks seem to be
mostly that it doesn't understand what we're doing. For example,
(1) it seems to be fooled by pass-by-reference Datums, probably
because the underlying type declaration is an integer type not void*.
(2) it doesn't seem to understand how we manage the element arrays
for dynahash tables, because it claims they're all possibly leaked;
(3) it claims strings passed to putenv() have been leaked;
... etc etc.

Admittedly, this is with RHEL6's valgrind which isn't too modern,
but the net result doesn't really motivate me to spend more time here.

regards, tom lane