public inbox for [email protected]  

help / color / mirror / Atom feed
From: Ayush Tiwari <[email protected]>
To: Tom Lane <[email protected]>
Cc: 王跃林 <[email protected]>
Cc: pgsql-bugs <[email protected]>
Cc: 3764353996 <[email protected]>
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
Date: Fri, 3 Jul 2026 22:18:13 +0530
Message-ID: <CAJTYsWUvzzik7uW-ZeqDELdpZV8ZxxfO4yx0_B8j1-8ndzgsGQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
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>
	<[email protected]>
	<CAJTYsWX1C5JLj92QdqEcArWs4XtXPog+yvyb6=X=_cghjXnkYQ@mail.gmail.com>
	<[email protected]>
	<CAJTYsWVus+7hn846A0gMJYk+9uUGZxizk5Herbxb4CmhF3vndQ@mail.gmail.com>
	<[email protected]>
	<CAJTYsWUg+ZH=W5EduH1AEDfJU0waO4uU4hakaiOF+KKUKFbR9g@mail.gmail.com>
	<[email protected]>

Hi,

On Fri, 3 Jul 2026 at 19:20, Tom Lane <[email protected]> wrote:

> Ayush Tiwari <[email protected]> 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


view thread (13+ messages)  latest in thread

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  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
  In-Reply-To: <CAJTYsWUvzzik7uW-ZeqDELdpZV8ZxxfO4yx0_B8j1-8ndzgsGQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox