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

Hi Amit,

I tested patch
v2-0001-Report-undefined-jsonpath-variable-when-no-variab.patch on:

REL_14_STABLE
REL_15_STABLE
REL_16_STABLE

Results:
The patch applies cleanly on all three branches.
Regression tests added/affected by the patch pass on all three branches:
REL_14: all relevant tests passed
REL_15: all relevant tests passed
REL_16: all relevant tests passed
The provided jsonpath reproducer query now consistently returns an error
about an undefined jsonpath variable on all three branches, which matches
the expected behavior change from this patch.

Conclusion:
The patch looks good from the testing side and can be merged.

ср, 17 июн. 2026 г. в 13:27, Amit Langote <amitlangote09(at)gmail(dot)com>:

> Hi Andrey,
>
> On Fri, Jun 5, 2026 at 7: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.
>
> 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
>

--
---
Regards,
Andrey Rachitskiy
Postgres Professional