Assertion failure in gserialized_gist_picksplit while creating gist index on geometry(LineString,4326) column

[bgandhi1]

PostgreSQL version:
=====================
select version();

PostgreSQL 10.5, compiled by Visual C++ build 1800, 64-bit

PostGIS version:
=====================
select PostGIS_full_version();

POSTGIS="2.4.3 r16312" PGSQL="100" GEOS="3.6.2-CAPI-1.10.2 4d2925d" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.3, released 2017/11/20 GDAL_DATA not found" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" RASTER

We have a PostgreSQL server with above PostGIS version details. In this server, in a given database, we have a column with type geometry(LineString, 4326). On this column, we try to create a GIST index like below:

CREATE INDEX index_name ON public.table_name USING gist (geom_linestring_col);

This results in PostgreSQL issuing an abort with a stack trace that looks like below:

MSVCR120!abort+0x34 [f:\dd\vctools\crt\crtw32\misc\abort.c,88]
postgres!ExceptionalCondition+0x4e [src\backend\utils\error\assert.c,54]
postgis_2_4!gserialized_gist_picksplit_2d+0xc87
postgres!FunctionCall2Coll+0x5c [src\backend\utils\fmgr\fmgr.c,1062]
postgres!gistUserPicksplit+0x98 [src\backend\access\gist\gistsplit.c,438]
postgres!gistSplitByKey+0x337 [src\backend\access\gist\gistsplit.c,697]
postgres!gistSplit+0x109 [src\backend\access\gist\gist.c,1373]
postgres!gistplacetopage+0x1d0 [src\backend\access\gist\gist.c,298]
postgres!gistdoinsert+0x4bf [src\backend\access\gist\gist.c,834]
postgres!gistBuildCallback+0x92 [src\backend\access\gist\gistbuild.c,491]
postgres!IndexBuildHeapRangeScan+0x6a5 [src\backend\catalog\index.c,2305]
postgres!IndexBuildHeapScan+0x38 [src\backend\catalog\index.c,2190]
postgres!gistbuild+0x21a [src\backend\access\gist\gistbuild.c,212]
postgres!index_build+0xb0 [src\backend\catalog\index.c,2058]
postgres!index_create+0x818 [src\backend\catalog\index.c,1126]
postgres!DefineIndex+0xa5b [src\backend\commands\indexcmds.c,680]
postgres!ProcessUtilitySlow+0x7cc [src\backend\tcop\utility.c,1334]
postgres!standard_ProcessUtility+0x8e3 [src\backend\tcop\utility.c,934]
[———rest of the stack snipped———-]

Upon debugging further into ExceptionalCondition code, we could see that the following assertion in postgis code was raised:

0:106> dv

fmt = 0x0000000b`81048d70 "TRAP: %s("%s", File: "%s", Line: %d)."
errbuf = char [2048] "TRAP: FailedAssertion("!(lower ≥ context.rightLower)", File: "gserialized_gist_2d.c", Line: 2075)."

We are able to consistently reproduce this with this table/column. Can we get help regarding if this is a known issue, or has been fixed in latest versions of PostGIS?

[Algunenano]

POSTGIS="2.4.3 r16312"

The latest 2.4.X release available is 2.4.6; it has a couple of fixes around the gserialized code but I'm not sure if they matter here.

We are able to consistently reproduce this with this table/column. Can we get help regarding if this is a known issue, or has been fixed in latest versions of PostGIS?

Can you share the table/column values or a subset that can be used to reproduce this?

[bgandhi1]

Part 1 of split of dump file

[bgandhi1]

Part 2 of split of dump file

[bgandhi1]

Part 3 of split of dump file

[bgandhi1]

Part 4 of split of dump file

[bgandhi1]

Part 5 of split of dump file

[bgandhi1]

I took a pg_dump of the table that reproduces issue for me. Since the table is ~21 MB, I split it using split command into 5 small files and attached here (since this site allows only 5.9 MB max). Once you've reassembled the attached files, you can pg_restore it to a PostgreSQL server (version details are in earlier comments).

In the dump file, there's only one table (t). This table has just one column, it is of type Geometry(LineString, 4326). Once you've restored it, run below create index command: CREATE INDEX index_name ON public.t USING gist (surface_bh_ls);

For me, this create index command causes the assertion failure reported here. Please let me know if you need any further information.

[bgandhi1]

were you able to reproduce this issue?

[pramsey]

No, not able to reproduce:

postgis24=# \d t 
                              Table "public.t"
    Column     |           Type            | Collation | Nullable | Default 
---------------+---------------------------+-----------+----------+---------
 surface_bh_ls | geometry(LineString,4326) |           |          | 

postgis24=# create index t_surface_bh_ls_x on t using gist(surface_bh_ls);
CREATE INDEX

postgis24=# select postgis_full_version();
NOTICE:  Function postgis_gdal_version() not found.  Is raster support enabled and rtpostgis.sql installed?
NOTICE:  Function postgis_raster_scripts_installed() not found. Is raster support enabled and rtpostgis.sql installed?
NOTICE:  Function postgis_raster_lib_version() not found. Is raster support enabled and rtpostgis.sql installed?
                                                                      postgis_full_version                                                                       
---------------------------------------------------------------------------------------------------------------------
 POSTGIS="2.4.8dev r17331" PGSQL="100" GEOS="3.8.0dev-CAPI-1.11.0 8d02a094" PROJ="Rel. 6.0.0, March 1st, 2019" LIBXML="2.9.4" LIBJSON="0.13" LIBPROTOBUF="1.3.1"
(1 row)

[pramsey]

However, the source of the problem is likely the Nan-valued vertices in the data? Do you know how you got those?

SELECT ST_AsText(surface_bh_ls)
FROM t
WHERE st_x(st_endpoint(surface_bh_ls)) =  double precision 'NaN';