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)
Список
Дерево обсуждения
Re: leak in libpq, getpwuid Michael Nacos <m.nacos@gmail.com>
Re: leak in libpq, getpwuid Tom Lane <tgl@sss.pgh.pa.us>
Re: leak in libpq, getpwuid Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: leak in libpq, getpwuid Michael Nacos <m.nacos@gmail.com>
Re: leak in libpq, getpwuid Craig Ringer <craig@postnewspapers.com.au>
Re: leak in libpq, getpwuid Michael Nacos <m.nacos@gmail.com>
Re: leak in libpq, getpwuid Tom Lane <tgl@sss.pgh.pa.us>
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 по дате отправления