Craig Ringer writes:
> On Tue, 2009-07-21 at 10:13 -0400, Tom Lane wrote:
>> It's not unusual for "top" to show the postmaster's child processes as
>> "postmaster" as well. Depends on the platform and the options given
>> to top.
> Ah. Thanks for clearing that one up. That'd make more sense, sin
On Tue, 2009-07-21 at 10:13 -0400, Tom Lane wrote:
> Craig Ringer writes:
> > I'm a bit puzzled about why you have three "postmaster" instances shown
> > as running.
>
> It's not unusual for "top" to show the postmaster's child processes as
> "postmaster" as well. Depends on the platform and the
Craig Ringer writes:
> I'm a bit puzzled about why you have three "postmaster" instances shown
> as running.
It's not unusual for "top" to show the postmaster's child processes as
"postmaster" as well. Depends on the platform and the options given
to top.
regards, tom la
On Tue, 2009-07-21 at 19:39 +0900, tanjunhua wrote:
> I'm sorry for the twice action. because the mail server reject my response.
> I should compress it with ciper code(11) and the execute program is
> compressed also.
When I build your example from source I see no indication of anything
wro
On Tue, 2009-07-21 at 13:53 +0900, tanjunhua wrote:
> I get the memory leak scenario not only from Valgrind, but also from the
> output of top command.
> At first I think the memory leak occur when I disconnect database by
> Valgrind, then I write a test sample that just connect and disconnect
Because of the three-day break, my response is late.
8.1.8 is pretty old.
Also you'll have better luck getting help if you actually include the
output
from Valgrind.
the output from Valgrind is not stored. from now on, I will do it again and
get the result from Valgrind.
PS: the memory leak
Because of the three-day break, my response is late.
Valgrind is a great tool, but you must learn how to identify false
positives and tell the difference between a leak that matters (say 1kb
allocated and not freed in a loop that runs once per second) and a leak
that doesn't.
I get the memory
Sorry for the reply-to-self, but I thought I'd take ecpg out of the
equation:
#include
#include
int main()
{
struct passwd p;
struct passwd * r;
char buf[500];
getpwuid_r(1000, &p, &buf[0], 500, &r);
}
... produces the same leak report.
Since you didn't include information li
Your test case doesn't build, but I've attached a trivially tweaked one
that does.
Valgrind's report (valgrind --leak-check=full ./test) on my Ubuntu 9.04
machine with Pg 8.3.7 is:
==23382== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely
lost in loss record 1 of 4
==23382==at
8.1.8 is pretty old.
Also you'll have better luck getting help if you actually include the output
from Valgrind.
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of tanjunhua
Sent: Friday, July 17, 2009 8:12 AM
To: Postgres G
10 matches
Mail list logo
