Re: Memory leaks

Поиск
Список
Период
Сортировка
От Nigel J. Andrews
Тема Re: Memory leaks
Дата
Msg-id Pine.LNX.4.21.0210230033440.27989-100000@ponder.fairway2k.co.uk
обсуждение исходный текст
Ответ на Re: Memory leaks  (Greg Copeland <greg@CopelandConsulting.Net>)
Ответы Re: Memory leaks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 22 Oct 2002, Greg Copeland wrote:

> On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
> 
> > plpgsql has some issues too, I suspect, but not as bad as pltcl etc.
> > 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?

I saw use of a couple of malloc (or Python specific malloc) calls the other day
but I also seem to recall that, after consideration, I decided the memory
needed to survive for the duration of the backend. Should I have created a new
child of the top context and changed these malloc calls?

I was going to ask about thoughts on redirecting malloc etc to palloc etc and
thereby intercepting memory allocation within the languages and automatically
bringing them into the memory context realm. However, that would just be making
life way too awkward, bearing in mind the above paragraph. Can't we get Sir
Mongle (or whatever the name was) to test these things under the auspices of
them being DoS attacks?


-- 
Nigel J. Andrews



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Copeland
Дата:
Сообщение: Re: Memory leaks
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_dump and large files - is this a problem?