Re: Memory leakage associated with plperl spi_prepare/spi_freeplan

Поиск
Список
Период
Сортировка
От Alex Hunsaker
Тема Re: Memory leakage associated with plperl spi_prepare/spi_freeplan
Дата
Msg-id CAFaPBrRNeP95DX=S-x=QJZMXBgZfYahiCTG56QmZeh4=ErwKVw@mail.gmail.com
обсуждение исходный текст
Ответ на Memory leakage associated with plperl spi_prepare/spi_freeplan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Memory leakage associated with plperl spi_prepare/spi_freeplan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers



On Tue, Feb 26, 2013 at 3:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm inclined to think the right fix is to make a small memory context
for each prepared plan made by plperl_spi_prepare().  The qdesc for it
could be made right in the context (getting rid of the unchecked
malloc's near the top of the function), the FmgrInfos and their
subsidiary data could live there too, and plperl_spi_freeplan could
replace its retail free's with a single MemoryContextDelete.


Seemed fairly trivial, find the above approach in the attached. I added a CHECK_FOR_INTERRUPTS() at the top of plperl_spi_prepare(), it was fairly annoying that I couldn't ctrl+c my way out of test function.

One annonce is it still leaks :-(. I tracked it down and it seemed to stem from parseTypeString().  I chased down the rabbit hole for a bit, but nothing jumped out... raw_parser() is a bit of a black box to me. Adding the seemingly obvious list_free(raw_parsetree_list); or setting the memory context before parseTypeString() didn't seem to do much.

It would be nice to squish the other leaks due to perm_fmgr_info()... but this is a start.
Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: Jonathan Rogers
Дата:
Сообщение: Re: Btrfs clone WIP patch