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 по дате отправления: