MIME-Version: 1.0
References: 
 <AH*AvQCYKhQGVvPWi1GiU4oY.8.1781609375063.Hmail.3020001251@tju.edu.cn>
 <CAJTYsWWSx+5-kVaivB_znaQCk3TmHrO4QNNM-CD3AN-oOSmG8w@mail.gmail.com>
 <AGoA0AD5KvwQ8G7e6ofMyap6.3.1781760245047.Hmail.3020001251@tju.edu.cn>
 <3748108.1783003096@sss.pgh.pa.us>
 <CAJTYsWX1C5JLj92QdqEcArWs4XtXPog+yvyb6=X=_cghjXnkYQ@mail.gmail.com>
 <3756776.1783011257@sss.pgh.pa.us>
 <CAJTYsWVus+7hn846A0gMJYk+9uUGZxizk5Herbxb4CmhF3vndQ@mail.gmail.com>
 <3793780.1783033337@sss.pgh.pa.us>
 <CAJTYsWUg+ZH=W5EduH1AEDfJU0waO4uU4hakaiOF+KKUKFbR9g@mail.gmail.com>
 <3854290.1783086630@sss.pgh.pa.us>
In-Reply-To: <3854290.1783086630@sss.pgh.pa.us>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Fri, 3 Jul 2026 22:18:13 +0530
Message-ID: 
 <CAJTYsWUvzzik7uW-ZeqDELdpZV8ZxxfO4yx0_B8j1-8ndzgsGQ@mail.gmail.com>
Subject: Re: Fw:Re: Fw: gbt_var_consistent in
 contrib/btree_gist/btree_utils_var.c
 has internal-node type confusion on the <> strategy,
 bypassing exclusion constraints
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: =?UTF-8?B?546L6LeD5p6X?= <violin0613@tju.edu.cn>,
	pgsql-bugs <pgsql-bugs@postgresql.org>, 3764353996 <3764353996@qq.com>
Content-Type: multipart/alternative; boundary="00000000000071a2210655b7b194"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWUvzzik7uW-ZeqDELdpZV8ZxxfO4yx0_B8j1-8ndzgsGQ%40mail.gmail.com>
Precedence: bulk

--00000000000071a2210655b7b194
Content-Type: text/plain; charset="UTF-8"

Hi,

On Fri, 3 Jul 2026 at 19:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Ayush Tiwari <ayushtiwari.slg01@gmail.com> writes:
> > Are you planning on including it in the backpatch or to keep the
> > optimization just part of master, and the bug fix backpatched?
>
> I was intending to back-patch only the bug fixes, ie 0002 and 0003.
> If we make additional cosmetic changes to gbt_var_consistent(),
> I could go either way on whether to include those in the back-patch.
>

Sounds good.


> BTW, thinking some more about 0004: isn't it pointless to check
> gbt_var_node_pf_match in the gbt_var_consistent cases that
> only constrain the lower bound, that is LessEqual and Less?  In
>
>                 retval = tinfo->f_cmp(query, key->lower, collation,
> flinfo) >= 0
>                     || gbt_var_node_pf_match(key, query, tinfo);
>
> if query >= key->lower then we must search the node, but if it
> isn't then the prefix match against upper can't succeed either.


Hmm, looks like the || gbt_var_node_pf_match(...) clause isn't
needed in the BTLessStrategyNumber and BTLessEqualStrategyNumber
cases.  Those only compare against the lower bound, and if query
sorts before lower then it sorts before upper too, so a prefix
match against the (truncated) upper can never succeed there.
I tried changing it locally and ran the regression tests, all passed.

Regards,
Ayush

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 3 Jul 20=
26 at 19:20, Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.=
pa.us</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">Ayush Tiwari &lt;<a href=3D"mailto:ayushtiwari.slg01@gmail.com" target=
=3D"_blank">ayushtiwari.slg01@gmail.com</a>&gt; writes:<br>
&gt; Are you planning on including it in the backpatch or to keep the<br>
&gt; optimization just part of master, and the bug fix backpatched?<br>
<br>
I was intending to back-patch only the bug fixes, ie 0002 and 0003.<br>
If we make additional cosmetic changes to gbt_var_consistent(),<br>
I could go either way on whether to include those in the back-patch.<br></b=
lockquote><div><br>Sounds good.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
BTW, thinking some more about 0004: isn&#39;t it pointless to check<br>
gbt_var_node_pf_match in the gbt_var_consistent cases that<br>
only constrain the lower bound, that is LessEqual and Less?=C2=A0 In<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retval =3D tinfo-&g=
t;f_cmp(query, key-&gt;lower, collation, flinfo) &gt;=3D 0<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 || gb=
t_var_node_pf_match(key, query, tinfo);<br>
<br>
if query &gt;=3D key-&gt;lower then we must search the node, but if it<br>
isn&#39;t then the prefix match against upper can&#39;t succeed either.<spa=
n style=3D"background-color:transparent">=C2=A0</span></blockquote><div><br=
>Hmm, looks like the || gbt_var_node_pf_match(...) clause isn&#39;t<br>need=
ed in the BTLessStrategyNumber and BTLessEqualStrategyNumber<br>cases.=C2=
=A0 Those only compare against the lower bound, and if query<br>sorts befor=
e lower then it sorts before upper too, so a prefix<br>match against the (t=
runcated) upper can never succeed there.<br>I tried changing it locally and=
 ran the regression tests, all passed.<br><br>Regards,<br>Ayush</div></div>=
</div>

--00000000000071a2210655b7b194--