Re: Memory leaks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Memory leaks
Date
Msg-id 27634.1035343703@sss.pgh.pa.us
Whole thread Raw
In response to Re: Memory leaks  (Greg Copeland <greg@CopelandConsulting.Net>)
Responses Re: Memory leaks  (Karel Zak <zakkr@zf.jcu.cz>)
Re: Memory leaks  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
Re: Memory leaks  (Greg Copeland <greg@CopelandConsulting.Net>)
List pgsql-hackers
Greg Copeland <greg@copelandconsulting.net> writes:
> On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
>> Yes, this has been dealt with before.

> What tools, aside from noggin v1.0, did they use?  Do we know?

s/they/me/ ... none.  But I don't know of any that I think would be
useful.

> I then moved on to psql, again, just for fun.  Here, I'm thinking that I
> started to find some other leaks...but again, I've not spent any real
> time on it.  So again, I'm not really sure it they are meaningful at
> this point.

psql might well have some internal leaks; the backend memory-context
design doesn't apply to it.

>> Possibly the best answer is to integrate the memory-context notion into
>> those modules; if they did most of their work in a temp context that
>> could be freed once per PL statement or so, the problems would pretty
>> much go away.

> Interesting.  Having not looked at memory management schemes used in the
> pl implementations, can you enlighten me by what you mean by "integrate
> the memory-context notion"?  Does that mean they are not using
> palloc/pfree stuff?

Not everywhere.  plpgsql is full of malloc's and I think the other PL
modules are too --- and that's not to mention the allocation policies of
the perl, tcl, etc, language interpreters.  We could use a thorough
review of that whole area.

> Well, the thing that really got my attention is that dmalloc is
> reporting frees on null pointers.

AFAIK that would dump core on many platforms (it sure does here...),
so I don't think I believe it without seeing chapter and verse.  But
if you can point out where it's really happening, then we must fix it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Memory leaks
Next
From: Justin Clift
Date:
Subject: Brazilian Portuguese version of the PostgreSQL "Advocacy and Marketing" site is ready