From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Fix netmask handling in inet_minmax_multi_ops |
Date: | 2023-03-26 16:48:45 |
Message-ID: | 200b709d-6b1d-54e6-971d-b9dec75bd8a8@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 3/20/23 10:28, Tomas Vondra wrote:
> Fix netmask handling in inet_minmax_multi_ops
>
> When calculating distance in brin_minmax_multi_distance_inet(), the
> netmask was applied incorrectly. This results in (seemingly) incorrect
> ordering of values, triggering an assert.
>
> For builds without asserts this is mostly harmless - we may merge other
> ranges, possibly resulting in slightly less efficient index. But it's
> still correct and the greedy algorithm doesn't guarantee optimality
> anyway.
>
> Backpatch to 14, where minmax-multi indexes were introduced.
>
> Reported by Dmitry Dolgov, investigation and fix by me.
>
> Reported-by: Dmitry Dolgov
Correction - the issue was reported by Robins Tharakan, I got confused
while writing the commit message. I don't know if this issue is to be
mentioned in release notes (considering it mostly affects just assert
builds), but if we do we should the correct name.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-03-26 17:41:16 | pgsql: Fix oversights in array manipulation. |
Previous Message | Peter Geoghegan | 2023-03-25 22:24:34 | Re: pgsql: amcheck: Fix verify_heapam for tuples where xmin or xmax is 0. |