Re: BUG #19000: gist index returns inconsistent result with gist_inet_ops

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Richard Guo <guofenglinux(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19000: gist index returns inconsistent result with gist_inet_ops
Date: 2025-07-31 15:43:18
Message-ID: d570c46d-1e20-4766-93de-c6fcbc18f282@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 28.07.25 04:23, Richard Guo wrote:
> On Mon, Jul 28, 2025 at 5:16 AM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> CREATE EXTENSION btree_gist;
>>
>> CREATE TABLE t AS SELECT '192.168.1.0/25'::inet AS i;
>>
>> SELECT * FROM t WHERE i << '192.168.1.0/24'::cidr;
>> i
>> ----------------
>> 192.168.1.0/25
>>
>> CREATE INDEX ON t USING gist(i);
>>
>> SELECT * FROM t WHERE i << '192.168.1.0/24'::cidr;
>> i
>> ---
>> (0 rows)
>
> It seems that with gist_inet_ops the index's opfamily does not support
> the '<<' operator correctly.
>
> With inet_ops, the query works correctly.

The generated index condition is the same for the gist and the btree
index, namely:

((i > '192.168.1.0/24'::inet) AND (i <= '192.168.1.255'::inet))

If I run the query with the lower bound directly, like

SELECT * FROM t WHERE i > '192.168.1.0/24'::inet;

then I also get no result rows for the gist index, but I do get one for
the btree index. (The upper bound works correctly in either case.)

This can be reproduced even in PG17.

My mind is a bit boggled about what the actual meaning of the > operator
should be in this case, but in any case it seems there might be a
pre-existing discrepancy in the btree_gist module.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Masahiko Sawada 2025-07-31 16:51:21 Re: Use-after-free in reorderbuffer.c for INSERT ON CONFLICT
Previous Message Vik Fearing 2025-07-31 13:10:09 Re: BUG #19003: A SELECT that does not return a valid table