MIME-Version: 1.0
References: <19458-a69c98bc498333ba@postgresql.org>
 <CAB8bMit1HvJsAasUYwmq+82Oa3zQhJyvsHNS4PGF_S_BCMnuVA@mail.gmail.com>
 <AE0E8193-85BD-4A10-BE23-582D92DA281D@yandex-team.ru>
 <CAN-LCVNh2z4EE+F21XPe7XRSWfPFtZx1WYAswpU5qs+RdR=jjg@mail.gmail.com>
 <6DE4A9D6-6D5C-41C0-8AFE-F51CFBDDAD5A@yandex-team.ru>
 <CAN-LCVPiBi9XXW__RorX=dH2_fANAMXhdbULmHFFg97F_0ubRw@mail.gmail.com>
 <674AEA44-D9C5-423D-B118-693CA130106E@yandex-team.ru>
 <CA+HiwqG5pP8g0oGkz8x6X80XJyZqGiS16F9DhvJ3Ukejkd8MbQ@mail.gmail.com>
In-Reply-To: 
 <CA+HiwqG5pP8g0oGkz8x6X80XJyZqGiS16F9DhvJ3Ukejkd8MbQ@mail.gmail.com>
From: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Date: Fri, 5 Jun 2026 15:03:11 +0500
Message-ID: 
 <CAB8bMivkf5X73X6LOSxt4r4tx_PN6DnGKVcBa3BtYX=eOKwHaw@mail.gmail.com>
Subject: Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with
 malformed JSONPath containing non-existent variables
To: Amit Langote <amitlangote09@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>,
 Nikita Malakhov <hukutoc@gmail.com>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
 Nikolay Shaplov <dhyan@nataraj.su>
Content-Type: multipart/alternative; boundary="0000000000005b8f2906537ec5c4"
Archived-At: 
 <https://www.postgresql.org/message-id/CAB8bMivkf5X73X6LOSxt4r4tx_PN6DnGKVcBa3BtYX%3DeOKwHaw%40mail.gmail.com>
Precedence: bulk

--0000000000005b8f2906537ec5c4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The growing allocation is leaked temporary JsonValueLists in
executePredicate() (local lseq/rseq, ~1482=E2=80=931547) and the arithmetic=
 helpers
executeBinaryArithmExpr() / executeUnaryArithmExpr() (~1561=E2=80=931684). =
Each
nested comparison or arithmetic subexpression materializes operands via
executeItemOptUnwrapResult[NoThrow]() =E2=86=92 executeNextItem() =E2=86=92
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=E2=80=93586).

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 $"=E2=80=A6" reference. The same leak mechanism is reachable w=
ithout
missing vars =E2=80=94 Tom Lane demonstrated this on master (5a2043bf713) w=
ith $[*]
? (@ < $) 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.

=D0=BF=D1=82, 5 =D0=B8=D1=8E=D0=BD. 2026=E2=80=AF=D0=B3. =D0=B2 13:58, Amit=
 Langote <amitlangote09@gmail.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
>

--0000000000005b8f2906537ec5c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">The growing allocation is leaked temporar=
y JsonValueLists in executePredicate() (local lseq/rseq, ~1482=E2=80=931547=
) and the arithmetic helpers executeBinaryArithmExpr() / executeUnaryArithm=
Expr() (~1561=E2=80=931684). Each nested comparison or arithmetic subexpres=
sion materializes operands via executeItemOptUnwrapResult[NoThrow]() =E2=86=
=92 executeNextItem() =E2=86=92 JsonValueListAppend() (~1165, ~2451), but t=
he interim lists are never freed before return. For @? specifically, execut=
eJsonPath() also leaks a local vals list in strict exists mode (~579=E2=80=
=93586).<br><br>Missing vars make the AFL case worse by returning null inst=
ead of error, so evaluation continues deep into nested $?()/comparisons ins=
tead of stopping at the first $&quot;=E2=80=A6&quot; reference. The same le=
ak mechanism is reachable without missing vars =E2=80=94 Tom Lane demonstra=
ted this on master (5a2043bf713) with $[*] ? (@ &lt; $) on a large array.<b=
r><br>Our missing-variable patch fixes the reported OOM and the @? semantic=
s bug by aborting early. Whether REL_14/15/16 also need a broader fix for i=
nterim JsonValueList cleanup is beyond what I can confidently propose; I=
9;ve tried to pin down where the growth happens for that discussion.<br></d=
iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">=D0=BF=D1=82, 5 =D0=B8=D1=8E=D0=BD. 2026=E2=80=AF=D0=B3.=
 =D0=B2 13:58, Amit Langote &lt;<a href=3D"mailto:amitlangote09@gmail.com">=
amitlangote09@gmail.com</a>&gt;:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Hi,<br>
<br>
Before I dig into the patch properly after the weekend, one question<br>
on the report itself: has anyone traced why the old path runs away on<br>
memory? We&#39;ve characterized it as missing-var, then null, then<br>
evaluation continues, then OOM, but I don&#39;t think the actual growing<br=
>
allocation has been pinned down. Mostly want to understand whether the<br>
same runaway is reachable without a missing variable, since raising<br>
the error early wouldn&#39;t catch those cases.<br>
<br>
- Thanks, Amit<br>
</blockquote></div></div>

--0000000000005b8f2906537ec5c4--