MIME-Version: 1.0
References: <19458-a69c98bc498333ba@postgresql.org> <CAB8bMit1HvJsAasUYwmq+82Oa3zQhJyvsHNS4PGF_S_BCMnuVA@mail.gmail.com>
 <AE0E8193-85BD-4A10-BE23-582D92DA281D@yandex-team.ru>
In-Reply-To: <AE0E8193-85BD-4A10-BE23-582D92DA281D@yandex-team.ru>
From: Nikita Malakhov <hukutoc@gmail.com>
Date: Tue, 28 Apr 2026 23:19:15 +0300
Message-ID: <CAN-LCVNh2z4EE+F21XPe7XRSWfPFtZx1WYAswpU5qs+RdR=jjg@mail.gmail.com>
Subject: Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with
 malformed JSONPath containing non-existent variables
To: Andrey Borodin <x4mmm@yandex-team.ru>, Amit Langote <amitlangote09@gmail.com>
Cc: Andrey Rachitskiy <pl0h0yp1@gmail.com>, pgsql-bugs@lists.postgresql.org, dhyan@nataraj.su
Content-Type: multipart/alternative; boundary="000000000000a21bdd06508af2f7"
Archived-At: <https://www.postgresql.org/message-id/CAN-LCVNh2z4EE%2BF21XPe7XRSWfPFtZx1WYAswpU5qs%2BRdR%3Djjg%40mail.gmail.com>
Precedence: bulk

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

Hi!

According to the Jsonpath standard, malformed expression should return an
error,
but not all cases of malformation are thoroughly described.

When this functionality was developed (Jsonpath and SQL/JSON) the absence
of the variable was considered as malformation and was decided to throw an
error
in threads long time ago. In case this behavior to be a subject for change
it surely
should not be backported, but the error-throwing code has to.
I agree that sometimes Json (-path) functionality provides very little info
on errors,
and it could be extended.

Changing this behavior is subject for Hackers and should be approved by Tom
Lane,
Adres Freund and other people responsible for including Jsonpath and
SQL/JSON
into Postgres.

On Tue, Apr 28, 2026 at 7:51=E2=80=AFPM Andrey Borodin <x4mmm@yandex-team.r=
u> wrote:

>
>
> > On 20 Apr 2026, at 18:38, Andrey Rachitskiy <pl0h0yp1@gmail.com> wrote:
> >
> > I propose a targeted backpatch for REL_14/15/16 in jsonpath_exec.c to
> align missing variable handling with newer branches and prevent
> pathological memory growth on malformed/hostile jsonpath expressions.
>
> Hi! Thank you for the report and proposed fix. I've took a look into the
> patch.
>
> So we can use vars like this:
>
> # SELECT jsonb_path_exists(
> '{"x": 42}'::jsonb,
> '$ ? ($"threshold" < 50)'::jsonpath,
> '{"threshold": 10}'::jsonb -- HERE go vars
> );
>
> Operator @? is doing the same, but without supplied vars. And this thread
> essentially points to buggy handling of vars:
>
> # SELECT j @? '$"no_such_var"'
> FROM (VALUES
>   ('{"important": "data"}'::jsonb),
>   ('42'::jsonb),
>   ('null'::jsonb),
>   ('false'::jsonb)
> ) AS t(j);
>  ?column?
> ----------
>  t
>  t
>  t
>  t
> (4 rows)
>
> It basically says that path with value of var "no_such_var" exists
> everywhere.
>
> I think it's a bug, but we would need a JSON Path expert here.
>
> 17+ throws an error, which seems suspicious to me too. @? is expected to
> operate in silent mode. Perhaps, we should just return NULL instead of t.
> By using RETURN_ERROR macro. But it might sound overly invasive for back
> branches.
>
> Even if we are going to throw an error, we can give mode details. I'd
> suggest
> instead of "could not find jsonpath variable \"%s\"" throwing something
> like
> "no variables supplied to reference by variable \"%s\"" or something alon=
g
> those lines.
>
>
> Besides this, the direction of the fix looks good to me. Thank you!
>
>
> Best regards, Andrey Borodin.
>
>
>
>

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

--000000000000a21bdd06508af2f7
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>According to the J=
sonpath standard, malformed expression should return an error,</div><div>bu=
t not all cases of malformation are thoroughly described.</div><div><br></d=
iv><div>When this functionality was developed (Jsonpath and SQL/JSON) the a=
bsence</div><div>of the variable was considered as malformation and was dec=
ided to throw an error</div><div>in threads long time ago. In case this beh=
avior to be=C2=A0a=C2=A0subject for change it=C2=A0surely</div><div>should =
not be backported,=C2=A0but the error-throwing code has to.</div><div>I agr=
ee that sometimes Json (-path) functionality provides very little info on e=
rrors,</div><div>and it could be extended.</div><div><br></div><div>Changin=
g this behavior is subject for Hackers and should be approved by Tom Lane,<=
/div><div>Adres Freund and other people responsible for including Jsonpath =
and SQL/JSON</div><div>into Postgres.</div><div><br></div></div><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Tue, Apr 28, 2026 at 7:51=E2=80=AFPM Andrey Borodin &lt;<a href=3D"mai=
lto:x4mmm@yandex-team.ru">x4mmm@yandex-team.ru</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
&gt; On 20 Apr 2026, at 18:38, Andrey Rachitskiy &lt;<a href=3D"mailto:pl0h=
0yp1@gmail.com" target=3D"_blank">pl0h0yp1@gmail.com</a>&gt; wrote:<br>
&gt; <br>
&gt; I propose a targeted backpatch for REL_14/15/16 in jsonpath_exec.c to =
align missing variable handling with newer branches and prevent pathologica=
l memory growth on malformed/hostile jsonpath expressions.<br>
<br>
Hi! Thank you for the report and proposed fix. I&#39;ve took a look into th=
e<br>
patch.<br>
<br>
So we can use vars like this:<br>
<br>
# SELECT jsonb_path_exists(<br>
&#39;{&quot;x&quot;: 42}&#39;::jsonb,<br>
&#39;$ ? ($&quot;threshold&quot; &lt; 50)&#39;::jsonpath,<br>
&#39;{&quot;threshold&quot;: 10}&#39;::jsonb -- HERE go vars<br>
);<br>
<br>
Operator @? is doing the same, but without supplied vars. And this thread<b=
r>
essentially points to buggy handling of vars:<br>
<br>
# SELECT j @? &#39;$&quot;no_such_var&quot;&#39;<br>
FROM (VALUES<br>
=C2=A0 (&#39;{&quot;important&quot;: &quot;data&quot;}&#39;::jsonb),<br>
=C2=A0 (&#39;42&#39;::jsonb),<br>
=C2=A0 (&#39;null&#39;::jsonb),<br>
=C2=A0 (&#39;false&#39;::jsonb)<br>
) AS t(j);<br>
=C2=A0?column?=C2=A0 <br>
----------<br>
=C2=A0t<br>
=C2=A0t<br>
=C2=A0t<br>
=C2=A0t<br>
(4 rows)<br>
<br>
It basically says that path with value of var &quot;no_such_var&quot; exist=
s everywhere.<br>
<br>
I think it&#39;s a bug, but we would need a JSON Path expert here.<br>
<br>
17+ throws an error, which seems suspicious to me too. @? is expected to<br=
>
operate in silent mode. Perhaps, we should just return NULL instead of t.<b=
r>
By using RETURN_ERROR macro. But it might sound overly invasive for back<br=
>
branches.<br>
<br>
Even if we are going to throw an error, we can give mode details. I&#39;d s=
uggest<br>
instead of &quot;could not find jsonpath variable \&quot;%s\&quot;&quot; th=
rowing something like<br>
&quot;no variables supplied to reference by variable \&quot;%s\&quot;&quot;=
 or something along<br>
those lines.<br>
<br>
<br>
Besides this, the direction of the fix looks good to me. Thank you!<br>
<br>
<br>
Best regards, Andrey Borodin.<br>
<br>
<br>
<br>
</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<br></div><div style=3D"=
color:rgb(34,34,34)">Postgres Professional</div><div style=3D"color:rgb(34,=
34,34)">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>

--000000000000a21bdd06508af2f7--