Re: Memory leak on subquery as scalar operand

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Memory leak on subquery as scalar operand
Дата
Msg-id 1084048.1667278336@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Memory leak on subquery as scalar operand  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Memory leak on subquery as scalar operand
Список pgsql-bugs
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?  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.

Also, as far as I can see there is no leak with the single-subquery
version.  The process's reported VIRT consumption bounces around a
fair amount, but it doesn't go above 300MB, even after ~10min in
a tight plpgsql DO loop.  VIRT bounces around a lot with the
two-subquery version too, actually, but there does seem to be a
general uptrend there.  I did not have the patience to wait for
actual OOM; it looked like it'd take a good long while, tens
of minutes at least.

If the behavior varies across LLVM versions, as is now seeming
a bit likely, it might be their bug not ours.

            regards, tom lane



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Memory leak on subquery as scalar operand
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Memory leak on subquery as scalar operand