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>
 <CAB8bMivkf5X73X6LOSxt4r4tx_PN6DnGKVcBa3BtYX=eOKwHaw@mail.gmail.com>
In-Reply-To: 
 <CAB8bMivkf5X73X6LOSxt4r4tx_PN6DnGKVcBa3BtYX=eOKwHaw@mail.gmail.com>
From: Nikita Malakhov <hukutoc@gmail.com>
Date: Fri, 5 Jun 2026 13:57:27 +0300
Message-ID: 
 <CAN-LCVP7dxvrvRTpRhZbfL8Obh_d4dvcQOfuOQC5aKukZ7+xRw@mail.gmail.com>
Subject: Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with
 malformed JSONPath containing non-existent variables
To: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>,
 Andrey Borodin <x4mmm@yandex-team.ru>,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
 Nikolay Shaplov <dhyan@nataraj.su>
Content-Type: multipart/alternative; boundary="00000000000086d3ef06537f87fe"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN-LCVP7dxvrvRTpRhZbfL8Obh_d4dvcQOfuOQC5aKukZ7%2BxRw%40mail.gmail.com>
Precedence: bulk

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

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=E2=80=AFPM Andrey Rachitskiy <pl0h0yp1@gmail.co=
m> wrote:

> The growing allocation is leaked temporary JsonValueLists in
> executePredicate() (local lseq/rseq, ~1482=E2=80=931547) and the arithmet=
ic 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 fre=
ed
> 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
> without missing vars =E2=80=94 Tom Lane demonstrated this on master (5a20=
43bf713)
> with $[*] ? (@ < $) on a large array.
>
> Our missing-variable patch fixes the reported OOM and the @? semantics bu=
g
> by aborting early. Whether REL_14/15/16 also need a broader fix for inter=
im
> JsonValueList cleanup is beyond what I can confidently propose; I've trie=
d
> 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, Am=
it 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
>>
>

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

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi!<div><br></div><div>Thank you very muc=
h for this investigation! I&#39;d take a look into the patch after the week=
end.</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 5, 2026 at 1:03=E2=80=AFPM Andr=
ey Rachitskiy &lt;<a href=3D"mailto:pl0h0yp1@gmail.com">pl0h0yp1@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div dir=3D"ltr">The growing allocation is leaked temporary=
 JsonValueLists in executePredicate() (local lseq/rseq, ~1482=E2=80=931547)=
 and the arithmetic helpers executeBinaryArithmExpr() / executeUnaryArithmE=
xpr() (~1561=E2=80=931684). Each nested comparison or arithmetic subexpress=
ion 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"><div dir=3D"ltr" class=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 La=
ngote &lt;<a href=3D"mailto:amitlangote09@gmail.com" target=3D"_blank">amit=
langote09@gmail.com</a>&gt;:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-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>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div style=3D"color:rgb(34,34,34)">Regards,</div=
><div style=3D"color:rgb(34,34,34)">Nikita Malakhov</div><div style=3D"colo=
r:rgb(34,34,34)">Postgres Professional</div><div style=3D"color:rgb(34,34,3=
4)">The Russian Postgres Company</div><div style=3D"color:rgb(34,34,34)"><a=
 href=3D"https://postgrespro.ru/" target=3D"_blank">https://postgrespro.ru/=
</a></div></div></div></div>

--00000000000086d3ef06537f87fe--