Re: leak in libpq, getpwuid
От | Craig Ringer |
---|---|
Тема | Re: leak in libpq, getpwuid |
Дата | |
Msg-id | 4AE19116.6090109@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: leak in libpq, getpwuid (Michael Nacos <m.nacos@gmail.com>) |
Ответы |
Re: leak in libpq, getpwuid
|
Список | 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 по дате отправления: