Re: Memory leak on subquery as scalar operand

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Memory leak on subquery as scalar operand
Дата
Msg-id 452E97A1-93EE-473C-A9D3-E878EF3543CF@yesql.se
обсуждение исходный текст
Ответ на Re: Memory leak on subquery as scalar operand  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: Memory leak on subquery as scalar operand  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-bugs
Attached is a v6 rebase of this patchset which curbs a memory leak in llvmjit
by explicitly using an LLVMContextRef for types which is dropped and recreated
at intervals to free unused types.  The attached graph plots the memory usage
of a backend continuously running the query from the OP in this thread.  The
patched version (running with all JIT costs at zero to get all inlining etc)
goes to a levelled off memory usage where master just continues to grow until
terminated.  There is more to do on llvmjit memory usage, but this is clearly a
win for queries which otherwise accumulte type leaks potentially ending with an
OOM.

0001 and 0002 are tangentially related, but are mainly of cleanup character.
0003 contains the LLVMContextRef work which is the meat of the patchset.

I think it would be good to get this in early in the v17 cycle such that we
have time to revisit the herustic if need be.

Thoughts?

--
Daniel Gustafsson






Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [16] ALTER SUBSCRIPTION ... SET (run_as_owner = ...) is a no-op
Следующее
От: Tom Lane
Дата:
Сообщение: Re: the same time value return different values,is it a problem