| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Michael Nacos <m(dot)nacos(at)gmail(dot)com> |
| Cc: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: leak in libpq, getpwuid |
| Date: | 2009-10-23 11:18:46 |
| Message-ID: | 4AE19116.6090109@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)RKC(dot)local>
Message-Id: <1247858675(dot)9349(dot)240(dot)camel(at)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Nacos | 2009-10-23 11:41:02 | Re: leak in libpq, getpwuid |
| Previous Message | Craig Ringer | 2009-10-23 11:10:09 | Re: auto-filling a field on insert |