Re: [HACKERS] Everything leaks; How it mm suppose to work?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Everything leaks; How it mm suppose to work? |
Дата | |
Msg-id | 199804091351.JAA12933@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Everything leaks; How it mm suppose to work? (dg@illustra.com (David Gould)) |
Список | pgsql-hackers |
> > Bruce: > > Maurice: > > > >Running postgresql in interactive mode shows that for each query I > > > >type there is memory lost. The exact amount of memory lost depends on > > > >the query I use. The amount of memory not freed is also a function > > > >of the number of tuples returned. > > > > > > > > > > Oops, it seems some palloced memory is not freed by pfree but > > > using some other function(s). > > > My mistake, sorry. > > > > > > > One thing I have found is that: > > > > select * from test where 1=0; > > > > do not leak memory while > > > > select * from test where x=-999; > > > > does leak memory, even though neither returns any rows. Strange. Would > > seem to point to the optimizer or executor. > > In the first case, the where clause is constant and evaluates false, so > not much is done. In the second case, the table is scanned and presumably > some memory is allocated for each row, probably to evaluate the expression. > Since this memory is allocated into a per statement duration, it will not > be freed until the end of the statement when the context is destroyed. This will be fixed in the 6.3.2 patch, due out soon. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: