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 :-)
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:
Michael Nacos 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 it. You'd have
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.
On Thu, Oct 22, 2009 at 3:46 PM, Tom Lane wrote:
> Michael Nacos 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
Michael Nacos 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 not worth fixin
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
int main()
{
PGconn *connection = PQconnectdb("user=postgres");
PQfinish(connection);
return 0;
}
gives
On Wed, Feb 18, 2009 at 5:47 PM, Tom Lane wrote:
> =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= 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: __n
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= 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
> /lib/i686/cmov/libc-2.7.so)
> =
On Tue, Feb 17, 2009 at 4:03 PM, Tom Lane wrote:
> =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= 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 ...
>
same thing on deb
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= 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 pgsql-general mailin
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
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
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
14 matches
Mail list logo
