Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with malformed JSONPath containing non-existent variables

Поиск
Список
Период
Сортировка
Искать
От
Amit Langote
Тема
Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with malformed JSONPath containing non-existent variables
Дата
в 11:27:25
Msg-id
CA+HiwqEL=Hr3ReVLqRy-U7JFOmx8ziS=_NLQcD4sA411kS5K9A@mail.gmail.com
Ответ на
Список
Дерево обсуждения
BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with malformed JSONPath containing non-existent variables PG Bug reporting form <noreply@postgresql.org>
Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with malformed JSONPath containing non-existent variables Amit Langote <amitlangote09@gmail.com>
Hi Andrey,

On Fri, Jun 5, 2026 at 7:03 PM Andrey Rachitskiy  wrote:
> The growing allocation is leaked temporary JsonValueLists in executePredicate() (local lseq/rseq, ~1482–1547) and the arithmetic helpers executeBinaryArithmExpr() / executeUnaryArithmExpr() (~1561–1684). Each nested comparison or arithmetic subexpression materializes operands via executeItemOptUnwrapResult[NoThrow]() → executeNextItem() → JsonValueListAppend() (~1165, ~2451), but the interim lists are never freed before return. For @? specifically, executeJsonPath() also leaks a local vals list in strict exists mode (~579–586).
>
> Missing vars make the AFL case worse by returning null instead of error, so evaluation continues deep into nested $?()/comparisons instead of stopping at the first $"…" reference. The same leak mechanism is reachable without missing vars — Tom Lane demonstrated this on master (5a2043bf713) with $[*] ? (@ < $) on a large array.
>
> Our missing-variable patch fixes the reported OOM and the @? semantics bug by aborting early. Whether REL_14/15/16 also need a broader fix for interim JsonValueList cleanup is beyond what I can confidently propose; I've tried to pin down where the growth happens for that discussion.

Thanks for that tracedown and for pointing to Tom's commit. The deeper
interim-JsonValueList leak looks unlikely to get fixed in the back
branches; Tom's cleanup (5a2043bf713) went only to master.

I'll look at committing the attached revised version of your Apr 20
patch (same fix, plus a regression test) down to REL_14. Please
check/test.

-- 
Thanks, Amit Langote
В списке pgsql-bugs по дате отправления
FAQ