Re: Memory leak on subquery as scalar operand

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Memory leak on subquery as scalar operand
Дата
Msg-id 20221101055132.pjjsvlkeo4stbjkq@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Memory leak on subquery as scalar operand  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Memory leak on subquery as scalar operand
Re: Memory leak on subquery as scalar operand
Список pgsql-bugs
Hi,

On 2022-11-01 00:52:16 -0400, Tom Lane wrote:
> David Rowley <dgrowleyml@gmail.com> writes:
> > The single subquery version also crashes for me, so perhaps it's just
> > the amount of memory that's being used and when the OOM killer is
> > triggering.
> > It crashes even when I set jit_inline_above_cost and
> > jit_optimize_above_cost above the query's cost.
> 
> Hmm, maybe we're not seeing the same thing?

I can't reproduce that either.


> For me, the behavior seems similar to what the OP reported: there's a
> per-query leakage but it's less than 100kB per query.  It'd take more than a
> handful of repetitions to get to an OOM failure.  This is with LLVM 13.0.1
> on RHEL 8.6.

This I can reproduce. Here's an updated patchset addressing this. This query,
for some reason, leaks a lot more aggressively than what I've seen in the
past, so I needed to reduce the amount of time until an llvm context is
recycled substantially. A bit of benchmarking showed no negative consequences
of going to 100 uses till recycling, even with absurd settings
(i.e. jit_*_cost = 0), but did show impact on lower values.

Greetings,

Andres Freund

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Memory leak on subquery as scalar operand
Следующее
От: "Gunnar \"Nick\" Bluth"
Дата:
Сообщение: Re: Strange sort node/explain result