public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: 王跃林 <[email protected]>
Cc: Ayush Tiwari <[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: Thu, 02 Jul 2026 10:38:16 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <AGoA0AD5KvwQ8G7e6ofMyap6.3.1781760245047.Hmail.3020001251@tju.edu.cn>
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>

=?UTF-8?B?546L6LeD5p6X?= <[email protected]> writes:
> The analysis and fix look correct. The BtreeGistNotEqual branch is
> the only strategy that bypasses the is_leaf check and passes
> potentially truncated internal-node keys directly to f_eq, which is
> unsafe for types like bit and varbit that require a minimum valid
> header size. Returning true for internal nodes is the right
> conservative choice and is consistent with how the other strategies
> handle the internal-node case.

None of this passes the smell test for me.  If it's unsafe to
call the type's f_eq function on a truncated key, how is it
any safer to call the f_cmp function?  IOW, why aren't *all* the
cases in gbt_var_consistent() broken?

It looks to me like gbt_var_node_truncate adjusts the length words
of the truncated keys so that they are still valid, just shorter.
Or at least it's trying to.  That works fine for text and bytea,
but it's not fine for bit/varbit because (a) it fails to update the
"bit_len" field that follows the length word, and (b) the common
prefix length selection logic doesn't know that it mustn't truncate
away any part of the bit_len field.  So my own thought about fixing
this is that type bit needs a custom truncation method.

It might well be that gbt_var_consistent's not-equal case is
broken too, but this discussion hasn't established that IMO.
(I continue to regret that we ever accepted such underdocumented code.
I think we ought to reverse-engineer a comment explaining what
gbt_var_consistent is doing, eg, why are all of the tests seemingly
reversed?)

			regards, tom lane

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

* 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