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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: 王跃林 <violin0613(at)tju(dot)edu(dot)cn>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, 3764353996 <3764353996(at)qq(dot)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
Date: 2026-07-03 13:50:30
Message-ID: 3854290.1783086630@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Baji Shaik 2026-07-03 16:34:51 Re: uuidv7 improperly accepts dates before 1970-01-01
Previous Message PG Bug reporting form 2026-07-03 13:25:52 BUG #19542: Boolean syntax in GRAPH_TABLE