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@gmail.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.
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.
