Re: leak in libpq, getpwuid - Mailing list pgsql-general

From Craig Ringer
Subject Re: leak in libpq, getpwuid
Date
Msg-id 4AE19116.6090109@postnewspapers.com.au
Whole thread Raw
In response to Re: leak in libpq, getpwuid  (Michael Nacos <m.nacos@gmail.com>)
Responses Re: leak in libpq, getpwuid
List pgsql-general
Michael Nacos wrote:
> I have just run some tests, the number of lost bytes is always 292, no
> matter how many connections are opened and closed.
> I guess it's ok, then.

Search the archives for a detailed explanation of this issue. The
earlier discussion was about a supposed leak in ecpg.

See:
 Message-ID: <022e01ca06e8$898255c0$aa1c10ac@RKC.local>
 Message-Id: <1247858675.9349.240.camel@ayaki>
on the -general list.

In brief: while technically a leak, it doesn't matter. Freeing that
memory would only ever be done immediately before a program exits.
Trying to free it introduces finalization ordering issues (what if
someone calls getpwnam(), getpwuid() etc after the cache is freed?) and
wastes CPU cycles. There's no point freeing memory when the whole
program is about to exit and its memory will be more efficiently
released by the OS.

The right answer to this is an addition to the default valgrind
suppressions file, not any change to glibc.

--
Craig Ringer

pgsql-general by date:

Previous
From: Craig Ringer
Date:
Subject: Re: auto-filling a field on insert
Next
From: Michael Nacos
Date:
Subject: Re: leak in libpq, getpwuid