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

Hi!

Thank you very much for this investigation! I'd take a look into the patch
after the weekend.

On Fri, Jun 5, 2026 at 1:03 PM Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> 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.
>
> пт, 5 июн. 2026 г. в 13:58, Amit Langote <amitlangote09(at)gmail(dot)com>:
>
>> Hi,
>>
>> Before I dig into the patch properly after the weekend, one question
>> on the report itself: has anyone traced why the old path runs away on
>> memory? We've characterized it as missing-var, then null, then
>> evaluation continues, then OOM, but I don't think the actual growing
>> allocation has been pinned down. Mostly want to understand whether the
>> same runaway is reachable without a missing variable, since raising
>> the error early wouldn't catch those cases.
>>
>> - Thanks, Amit
>>
>

--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/