Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tender Wang <tndrwang@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2025-08-01T04:53:23Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. ecpg: Fix memory leaks in ecpg_auto_prepare()

Tender Wang <tndrwang@gmail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> 于2025年8月1日周五 11:33写道：
>> Richard Guo <guofenglinux@gmail.com> writes:
>>> On Fri, Aug 1, 2025 at 3:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> We've known about this for, um, decades: btree_gist's support for
>>>> inet/cidr is fundamentally broken [1][2].

> What I debugged yesterday was, in  gbt_inet_consistent(),
> 	query = convert_network_to_scalar(dquery, INETOID, &failure);

Right --- as I mentioned in one of the linked threads, the thing that
is fundamentally wrong here is relying on convert_network_to_scalar
in the first place.  That has no charter to deliver exact results,
and it doesn't.  In the present example I think the issue is that
it doesn't consider the netmask at all; but there are many other
cases where it's not an exact representation of inet's sort order.
That's not a big problem for its intended purpose for statistical
estimates, but it's completely fatal for index infrastructure.

			regards, tom lane