Re: BUG #19700: PostgreSQL: an SP-GiST index on `inet` makes IPv6 rows invisible - Mailing list pgsql-bugs

From Kirill Reshke
Subject Re: BUG #19700: PostgreSQL: an SP-GiST index on `inet` makes IPv6 rows invisible
Date
Msg-id CALdSSPiNRiL8CLxPTmg4u+_8k8MKwfRWxg=Hjk934Y1jYcifFA@mail.gmail.com
Whole thread
In response to Re: BUG #19700: PostgreSQL: an SP-GiST index on `inet` makes IPv6 rows invisible  (Kirill Reshke <reshkekirill@gmail.com>)
Responses Re: BUG #19700: PostgreSQL: an SP-GiST index on `inet` makes IPv6 rows invisible
List pgsql-bugs
On Mon, 21 Sept 2026 at 11:05, Kirill Reshke <reshkekirill@gmail.com> wrote:

> With this (obvious?) diff issue disappears:
>
> reshke@reshke:~/postgres$ git diff src/backend/utils/adt/network_spgist.c
> diff --git a/src/backend/utils/adt/network_spgist.c
> b/src/backend/utils/adt/network_spgist.c
> index 52e3c666d4f..1cd065f57c4 100644
> --- a/src/backend/utils/adt/network_spgist.c
> +++ b/src/backend/utils/adt/network_spgist.c
> @@ -191,9 +191,8 @@ inet_spg_picksplit(PG_FUNCTION_ARGS)
>
>                 if (ip_bits(tmp) < commonbits)
>                         commonbits = ip_bits(tmp);
> -               commonbits = bitncommon(ip_addr(prefix), ip_addr(tmp),
> commonbits);
> -               if (commonbits == 0)
> -                       break;
> +               if (commonbits != 0)
> +                       commonbits = bitncommon(ip_addr(prefix),
> ip_addr(tmp), commonbits);
>         }
>
>         /* Don't need labels; allocate output arrays */
>
> --
> Best regards,
> Kirill Reshke


This hits assert
/* allTheSame isn't possible for such a tuple */
Assert(!in->allTheSame);



```
Program received signal SIGABRT, Aborted.
0x00007f54fe69eb2c in pthread_kill () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f54fe69eb2c in pthread_kill () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f54fe64527e in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f54fe6288ff in abort () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x0000563787e6093f in ExceptionalCondition
(conditionName=conditionName@entry=0x563787ef0ff8 "!in->allTheSame",
fileName=fileName@entry=0x563787ef0fe7 "network_spgist.c",
    lineNumber=lineNumber@entry=85) at assert.c:65
#4  0x0000563787db5fb2 in inet_spg_choose (fcinfo=<optimized out>) at
network_spgist.c:85
#5  0x0000563787e6b46e in FunctionCall2Coll
(flinfo=flinfo@entry=0x5637c16b8bb0, collation=<optimized out>,
arg1=arg1@entry=140721627228416, arg2=arg2@entry=140721627228464) at
fmgr.c:1163
#6  0x000056378797be95 in spgdoinsert
(index=index@entry=0x7f54fe996898, state=state@entry=0x7ffc4e9a6af0,
heapPtr=heapPtr@entry=0x5637c16b7908,
datums=datums@entry=0x7ffc4e9a6c80,
    isnulls=isnulls@entry=0x7ffc4e9a6c60) at spgdoinsert.c:2188
#7  0x000056378797e087 in spginsert (index=0x7f54fe996898,
values=0x7ffc4e9a6c80, isnull=0x7ffc4e9a6c60, ht_ctid=0x5637c16b7908,
heapRel=<optimized out>, checkUnique=<optimized out>,
    indexUnchanged=false, indexInfo=0x5637c16b8470) at spginsert.c:206
#8  0x0000563787ae42cd in ExecInsertIndexTuples
(resultRelInfo=resultRelInfo@entry=0x5637c16b6c30,
estate=estate@entry=0x5637c16b66e0, flags=flags@entry=0,
slot=slot@entry=0x5637c16b78d0,
    arbiterIndexes=arbiterIndexes@entry=0x0,
specConflict=specConflict@entry=0x0) at execIndexing.c:449
#9  0x0000563787b1aafd in ExecInsert
(context=context@entry=0x7ffc4e9a6f00,
resultRelInfo=resultRelInfo@entry=0x5637c16b6c30,
slot=slot@entry=0x5637c16b78d0, canSetTag=<optimized out>,
    inserted_tuple=inserted_tuple@entry=0x0,
insert_destrel=insert_destrel@entry=0x0) at nodeModifyTable.c:1272
#10 0x0000563787b1c457 in ExecModifyTable (pstate=0x5637c16b6a20) at
nodeModifyTable.c:4712
#11 0x0000563787ae503b in ExecProcNode (node=0x5637c16b6a20) at
../../../src/include/executor/executor.h:327
#12 ExecutePlan (dest=0x5637c176e3f0, direction=<optimized out>,
numberTuples=0, sendTuples=false, operation=CMD_INSERT,
queryDesc=0x5637c16b5af0) at execMain.c:1766
#13 standard_ExecutorRun (queryDesc=0x5637c16b5af0,
direction=<optimized out>, count=0) at execMain.c:377
#14 0x0000563787cf9f7b in ProcessQuery (plan=<optimized out>,
sourceText=0x5637c168c960 "INSERT INTO inet19700 VALUES ('8000::1');",
params=0x0, queryEnv=0x0, dest=0x5637c176e3f0, qc=0x7ffc4e9a7240)
    at pquery.c:162
#15 0x0000563787cfabae in PortalRunMulti
(portal=portal@entry=0x5637c17121f0, isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false,
dest=dest@entry=0x5637c176e3f0,
    altdest=altdest@entry=0x5637c176e3f0, qc=qc@entry=0x7ffc4e9a7240)
at pquery.c:1269
#16 0x0000563787cfafd2 in PortalRun
(portal=portal@entry=0x5637c17121f0,
count=count@entry=9223372036854775807,
isTopLevel=isTopLevel@entry=true, dest=dest@entry=0x5637c176e3f0,
    altdest=altdest@entry=0x5637c176e3f0, qc=qc@entry=0x7ffc4e9a7240)
at pquery.c:784
#17 0x0000563787cf6b1d in exec_simple_query
(query_string=0x5637c168c960 "INSERT INTO inet19700 VALUES
('8000::1');") at postgres.c:1297
#18 0x0000563787cf87c6 in PostgresMain (dbname=<optimized out>,
username=<optimized out>) at postgres.c:4946
#19 0x0000563787cf2673 in BackendMain (startup_data=<optimized out>,
startup_data_len=<optimized out>) at backend_startup.c:124
#20 0x0000563787c30021 in postmaster_child_launch
(child_type=<optimized out>, child_slot=2,
startup_data=startup_data@entry=0x7ffc4e9a7710,
startup_data_len=startup_data_len@entry=24,
    client_sock=client_sock@entry=0x7ffc4e9a7730) at launch_backend.c:268
#21 0x0000563787c33cb2 in BackendStartup (client_sock=0x7ffc4e9a7730)
at postmaster.c:3640
#22 ServerLoop () at postmaster.c:1727
#23 0x0000563787c358ad in PostmasterMain (argc=argc@entry=3,
argv=argv@entry=0x5637c16861b0) at postmaster.c:1414
#24 0x00005637878d850e in main (argc=3, argv=0x5637c16861b0) at main.c:227
(gdb)

```

repro is alike [0]

CREATE TABLE inet19700 (c inet);
CREATE INDEX inet19700_idx ON inet19700 USING spgist (c inet_ops);

INSERT INTO inet19700 SELECT '10.0.0.1' FROM generate_series(1, 290);

--   TRAP: FailedAssertion("!in->allTheSame")
INSERT INTO inet19700 VALUES ('8000::1');

So,  I updated inet_spg_choose to support the 'allTheSame' case. While
inserting, simply redirect to the first node.
inet_spg_inner_consistent needs the same fix  (otherwise index scans
would hit the same assertion.)


[0] https://www.postgresql.org/message-id/flat/537BE1A9.1050006@sigaev.ru




--
Best regards,
Kirill Reshke

Attachment

pgsql-bugs by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: BUG #19700: PostgreSQL: an SP-GiST index on `inet` makes IPv6 rows invisible
Next
From: Ayush Tiwari
Date:
Subject: Re: BUG #19710: Incorrect DELETE result after LEFT JOIN optimization