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:
thanks... I guess if it really mattered it would have come up by now
(since so many interfaces are based on libpq)
toying with the idea of yet another one :-)
just to say I have run into related problems on debian lenny amd64 (postgres
8.3.5, libc-2.7) and centos 5.2 (postgres 8.4.1, libc-2.5)
code as simple as this:
#include libpq-fe.h
int main()
{
PGconn *connection = PQconnectdb(user=postgres);
PQfinish(connection);
return 0;
Michael Nacos m.na...@gmail.com writes:
just to say I have run into related problems on debian lenny amd64 (postgres
8.3.5, libc-2.7) and centos 5.2 (postgres 8.4.1, libc-2.5)
This is not a Postgres bug. You can try filing it against glibc, but
I wouldn't be too surprised if they tell you it's
On Thu, Oct 22, 2009 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Michael Nacos m.na...@gmail.com writes:
just to say I have run into related problems on debian lenny amd64
(postgres
8.3.5, libc-2.7) and centos 5.2 (postgres 8.4.1, libc-2.5)
This is not a Postgres bug. You can try
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.
M.
Michael Nacos m.na...@gmail.com writes:
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.
Yeah. I suspect the memory is in fact not leaked, but valgrind is
somehow missing the link that points to
On Tue, Feb 17, 2009 at 4:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes:
oh, and note that I kind of rulled out linux libc/distro problem, same
happens on both centos 4.7 and fedora 9.
That hardly constitutes a wide sample of linux
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes:
same thing on debian, well - almost:
==8261==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==8261==by 0x43B1930: (within /lib/i686/cmov/libc-2.7.so)
==8261==by 0x43B222B: __nss_database_lookup (in
On Wed, Feb 18, 2009 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes:
same thing on debian, well - almost:
==8261==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==8261==by 0x43B1930: (within /lib/i686/cmov/libc-2.7.so)
oh, and note that I kind of rulled out linux libc/distro problem, same
happens on both centos 4.7 and fedora 9.
strangely.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Grzegorz Ja??kiewicz wrote:
Hey folks,
I am getting leaks on my machine, valgrind points to getpwuid_r called
by libpq's PQConnectDb()
==11784== 32,772 bytes in 1 blocks are indirectly lost in loss record 31 of 31
==11784==at 0x4004BA2: calloc (vg_replace_malloc.c:397)
==11784==
thanks Bruce,
In fact - the more weird fact is, that it still happens on
fedora9+8.4, but I can't get it anymore on centos+8.3.5
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes:
oh, and note that I kind of rulled out linux libc/distro problem, same
happens on both centos 4.7 and fedora 9.
That hardly constitutes a wide sample of linux distros ...
regards, tom lane
--
Sent via
14 matches
Mail list logo
