BUG #16283: crash on create index segmentation fault

On Fri, Feb 28, 2020 at 02:23:21PM +0000, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 16283
Logged by: Przemysław Szustak
Email address: przemyslaw.szustak@gmail.com
PostgreSQL version: 10.12
Operating system: Ubuntu 16.04.6 LTS
Description:

Postgresql crash segmentation fault on create index.
More info https://github.com/przemyslaw-szustak/postgresql_postgis_crash.

This seems more like a bug in postgis, considering the last frame before
the segfault looks like this:

#0 0x000055fb9015c45b in pfree ()
#1 0x00007f64ee7f2b5e in ?? () from /usr/lib/postgresql/10/lib/postgis-2.5.so
#2 0x00007f64ee7f4367 in gserialized_gist_picksplit () from /usr/lib/postgresql/10/lib/postgis-2.5.so
#3 0x000055fb9013a272 in FunctionCall2Coll ()
#4 0x000055fb8fd7f526 in gistSplitByKey ()

so it's a call from GiST, but the last two calls are somewhere in
PostGIS library. If I had to guess, I'd say this looks like double-free
or something like that.

Which PostGIS version are you using? Are you sure you have the latest
2.5.x version?

Also, maybe try to install packages with debug symbols, that should give
us a bit more context (parameters, line numbers, ...).

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

I don't know why but now when I created this howto recreate crash I used
new cluster (on these same server) and now system crash file is not created.
So now I have only info that postgres process has Segmentation fault.

I think that problem is in
https://github.com/postgis/postgis/blob/master/postgis/gserialized_gist_nd.c#L1378.
<https://remote.lehmann-partner.pl/owa/redir.aspx?C=f49ce336d2324e4aa836bade6a95d11a&amp;URL=https%3a%2f%2fgithub.com%2fpostgis%2fpostgis%2fblob%2fmaster%2fpostgis%2fgserialized_gist_nd.c%23L1378&gt;
I have had latest postgis from ubuntu apt update (POSTGIS="2.5.3 r17699"
[EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2,
08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3"
LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER).

So maybe I should report it to postgis bug tracking system?

pt., 28 lut 2020 o 17:26 Tomas Vondra <tomas.vondra@2ndquadrant.com>
napisał(a):

On Fri, Feb 28, 2020 at 02:23:21PM +0000, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 16283
Logged by: Przemysław Szustak
Email address: przemyslaw.szustak@gmail.com
PostgreSQL version: 10.12
Operating system: Ubuntu 16.04.6 LTS
Description:

Postgresql crash segmentation fault on create index.
More info https://github.com/przemyslaw-szustak/postgresql_postgis_crash.

This seems more like a bug in postgis, considering the last frame before
the segfault looks like this:

#0 0x000055fb9015c45b in pfree ()
#1 0x00007f64ee7f2b5e in ?? () from /usr/lib/postgresql/10/lib/
postgis-2.5.so
#2 0x00007f64ee7f4367 in gserialized_gist_picksplit () from
/usr/lib/postgresql/10/lib/postgis-2.5.so
#3 0x000055fb9013a272 in FunctionCall2Coll ()
#4 0x000055fb8fd7f526 in gistSplitByKey ()

so it's a call from GiST, but the last two calls are somewhere in
PostGIS library. If I had to guess, I'd say this looks like double-free
or something like that.

Which PostGIS version are you using? Are you sure you have the latest
2.5.x version?

Also, maybe try to install packages with debug symbols, that should give
us a bit more context (parameters, line numbers, ...).

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--

Z poważaniem,
Przemysław Szustak

On Fri, Feb 28, 2020 at 06:43:40PM +0100, Przemysław Szustak wrote:

I don't know why but now when I created this howto recreate crash I used
new cluster (on these same server) and now system crash file is not created.
So now I have only info that postgres process has Segmentation fault.

You probably need to tweak kernel.core_pattern - some systems have
custom scripts to process core files etc.

I think that problem is in
https://github.com/postgis/postgis/blob/master/postgis/gserialized_gist_nd.c#L1378.
<https://remote.lehmann-partner.pl/owa/redir.aspx?C=f49ce336d2324e4aa836bade6a95d11a&amp;URL=https%3a%2f%2fgithub.com%2fpostgis%2fpostgis%2fblob%2fmaster%2fpostgis%2fgserialized_gist_nd.c%23L1378&gt;
I have had latest postgis from ubuntu apt update (POSTGIS="2.5.3 r17699"
[EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2,
08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3"
LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER).

Yeah, that seems like the most recent version.

So maybe I should report it to postgis bug tracking system?

Maybe, but I guess they'll ask you for the same information.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

I updated info on github logs because now system was generated new core
dump.

How can I get you more information? I don't now how to debug it.

pt., 28 lut 2020 o 19:11 Tomas Vondra <tomas.vondra@2ndquadrant.com>
napisał(a):

On Fri, Feb 28, 2020 at 06:43:40PM +0100, Przemysław Szustak wrote:

I don't know why but now when I created this howto recreate crash I used
new cluster (on these same server) and now system crash file is not

created.

So now I have only info that postgres process has Segmentation fault.

You probably need to tweak kernel.core_pattern - some systems have
custom scripts to process core files etc.

I think that problem is in

https://github.com/postgis/postgis/blob/master/postgis/gserialized_gist_nd.c#L1378
.

<

https://remote.lehmann-partner.pl/owa/redir.aspx?C=f49ce336d2324e4aa836bade6a95d11a&amp;URL=https%3a%2f%2fgithub.com%2fpostgis%2fpostgis%2fblob%2fmaster%2fpostgis%2fgserialized_gist_nd.c%23L1378

I have had latest postgis from ubuntu apt update (POSTGIS="2.5.3 r17699"
[EXTENSION] PGSQL="100" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel.

4.9.2,

08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3"
LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER).

Yeah, that seems like the most recent version.

So maybe I should report it to postgis bug tracking system?

Maybe, but I guess they'll ask you for the same information.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--

Z poważaniem,
Przemysław Szustak

On Fri, Feb 28, 2020 at 08:58:19PM +0100, Przemysław Szustak wrote:

I updated info on github logs because now system was generated new core
dump.

How can I get you more information? I don't now how to debug it.

Well, it's hard to say what exactly is happening, without getting a
better backtrace. Your system is apparently missing debug symbols, so
you need to do something like

sudo aptitude install postgresql-10-dbg

or something like that. And the same for postgis, I assume. Then
generate the backtrace again (using the existing core file).

You might also attach gdb to the running backend, trigger the issue
and do more investigation there.

1) determine the PID of the backend handling your connection

db=# select pg_backend_pid();

2) attach GDB to the process

$ gdb -p $PID
(gdb) c

3) Run the query using the same backend, once it triggers you'll be able
to do 'bt' in the gdb shell and inspect variables.

This needs the debug symbols too, though.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

I installed postgresql-10-dbg. I can't find how to do it in postgis.
sudo apt install postgis(tab tab)
postgis postgis-doc postgis-gui
sudo apt install postgresql-10-postgis-(tab tab)
postgresql-10-postgis-2.4 postgresql-10-postgis-2.4-scripts
postgresql-10-postgis-2.5 postgresql-10-postgis-2.5-scripts
postgresql-10-postgis-3 postgresql-10-postgis-3-scripts

I updated github info.
New logs from core dump was available below '*new crash dump file generated
after install postgres dbg and run gbd -p 'postgres-10-PID*''.
I generated bt from old dump crash too.

pt., 28 lut 2020 o 22:00 Tomas Vondra <tomas.vondra@2ndquadrant.com>
napisał(a):

On Fri, Feb 28, 2020 at 08:58:19PM +0100, Przemysław Szustak wrote:

I updated info on github logs because now system was generated new core
dump.

How can I get you more information? I don't now how to debug it.

Well, it's hard to say what exactly is happening, without getting a
better backtrace. Your system is apparently missing debug symbols, so
you need to do something like

sudo aptitude install postgresql-10-dbg

or something like that. And the same for postgis, I assume. Then
generate the backtrace again (using the existing core file).

You might also attach gdb to the running backend, trigger the issue
and do more investigation there.

1) determine the PID of the backend handling your connection

db=# select pg_backend_pid();

2) attach GDB to the process

$ gdb -p $PID
(gdb) c

3) Run the query using the same backend, once it triggers you'll be able
to do 'bt' in the gdb shell and inspect variables.

This needs the debug symbols too, though.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--

Z poważaniem,
Przemysław Szustak

Hi,

On Mon, Mar 02, 2020 at 08:18:00PM +0100, Przemysław Szustak wrote:

I installed postgresql-10-dbg. I can't find how to do it in postgis.
sudo apt install postgis(tab tab)
postgis postgis-doc postgis-gui
sudo apt install postgresql-10-postgis-(tab tab)
postgresql-10-postgis-2.4 postgresql-10-postgis-2.4-scripts
postgresql-10-postgis-2.5 postgresql-10-postgis-2.5-scripts
postgresql-10-postgis-3 postgresql-10-postgis-3-scripts

Not sure, but there should be postgis-dbgsym package, I think.

I updated github info.

I find it rather annoying that we're discussing here but the relevant
debug info is somewhere on github, getting updated. That makes is almost
impossible for anyone to follow the discussion after a while. Please
copy the important bits here in the future (attach them as a file, if
necessary).

New logs from core dump was available below '*new crash dump file generated
after install postgres dbg and run gbd -p 'postgres-10-PID*''.
I generated bt from old dump crash too.

Well, both crashes fail at the same place - the last three frames look
like this:

#0 pfree (pointer=0x7f7a6e4068f8) at /build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c:954
#1 0x00007f7a65e39b5e in ?? () from /usr/lib/postgresql/10/lib/postgis-2.5.so
#2 0x00007f7a65e3b367 in gserialized_gist_picksplit () from /usr/lib/postgresql/10/lib/postgis-2.5.so

which means it fails here:

void
pfree(void *pointer)
{
MemoryContext context = GetMemoryChunkContext(pointer);

(*context->methods->free_p) (context, pointer); <------
VALGRIND_MEMPOOL_FREE(context, pointer);
}

So the pointer passed to pfree() may be actually OK, but one of the
pointers (context, methods or free_p) is probably somehow borked. It's
hard to say from the backtrace, you'll have to inspect that from gdb
(see my previous message for basic instructions).

You'll probably need to install the postgis debug symbols first, but
maybe try without it.

Are you able to extract some subset of the data, so that people can
reproduce this locally?

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

OK, once again all info:

Used versions:
Postgresql:
psql -p 5432 -c "select version()" -d "test_crash"
return:
PostgreSQL 10.12 (Ubuntu 10.12-2.pgdg16.04+1) on
x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0
20160609, 64-bit
Postgis:
psql -p 5432 -c "select postgis_full_version()" -d "test_crash"
return:
POSTGIS="2.5.3 r17699" [EXTENSION] PGSQL="100"
GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2, 08 September 2015"
GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99"
LIBPROTOBUF="1.2.1" RASTER
System:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial
uname -a
Linux 4.4.0-165-generic #193-Ubuntu SMP Tue Sep 17 17:42:52 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux

How to restore crash:
1. Create DB:
psql -p 5432 -c "create database test_crash"
2. Add postgis:
psql -p 5432 -c "create extension postgis" -d "test_crash"
3. Import data to DB (file "test_table.sql" in attachment):
psql -p 5432 -f "./test_table.sql" -d "test_crash"
4. Exec SQL:
psql -p 5432 -c "drop index if exists test_table_geom_idx; CREATE
INDEX test_table_geom_idx ON public.test_table USING gist(st_intersection
gist_geometry_ops_nd) TABLESPACE pg_default;" -d "test_crash"
5. Program terminated with signal SIGSEGV, Segmentation fault.

How I generate crash and bt log (using your information and PostGIS
tutorial https://trac.osgeo.org/postgis/wiki/DevWikiGettingABackTrace).
1. Login as postgres:
sudo su; su postgres

2. Open psql console:
psql -p 5432 -d "test_crash".

3. I try to check running pid:
select postgis_full_version(), pg_backend_pid();
return:

postgis_full_version
|
pg_backend_pid

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------
POSTGIS="2.5.3 r17699" [EXTENSION] PGSQL="100"
GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2, 08 September 2015"
GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99"
LIBPROTOBUF="1.2.1" RASTER | 30691
(1 row)

4. In other console:
sudo su;
gdb -p 30691

5. In first console (in psql) I run crash SQL:
drop index if exists test_table_geom_idx; CREATE INDEX
test_table_geom_idx ON public.test_table USING gist(st_intersection
gist_geometry_ops_nd) TABLESPACE pg_default;

6. In secend console (gdb) I press c
(gbd) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
pfree (pointer=0x7f7a6ec008f8) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c:954
954
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c:
Nie ma takiego pliku ani katalogu.

(gdb) bt
#0 pfree (pointer=0x7f7a6ec008f8) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/mmgr/mcxt.c:954
#1 0x00007f7a65c0eb5e in ?? () from /usr/lib/postgresql/10/lib/
postgis-2.5.so
#2 0x00007f7a65c10367 in gserialized_gist_picksplit () from
/usr/lib/postgresql/10/lib/postgis-2.5.so
#3 0x000055b80d1f6272 in FunctionCall2Coll
(flinfo=flinfo@entry=0x55b80ef2dac8,
collation=<optimized out>, arg1=arg1@entry=94249013099592,
arg2=arg2@entry=140736435822256)
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/utils/fmgr/fmgr.c:1059
#4 0x000055b80ce3b526 in gistUserPicksplit (len=227,
giststate=0x55b80ef2bca8, itup=0x55b80ef21d18, v=0x7fffc1439eb0, attno=0,
entryvec=0x55b80ef23c48, r=0x7f7a5705d668)
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistsplit.c:433
#5 gistSplitByKey (r=r@entry=0x7f7a5705d668,
page=page@entry=0x7f7a6ebfea00
"", itup=itup@entry=0x55b80ef21d18, len=len@entry=227,
giststate=giststate@entry=0x55b80ef2bca8, v=v@entry=0x7fffc1439eb0, attno=0)
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistsplit.c:697
#6 0x000055b80ce3252c in gistSplit (r=r@entry=0x7f7a5705d668,
page=page@entry=0x7f7a6ebfea00 "", itup=0x55b80ef21d18, len=227,
giststate=giststate@entry=0x55b80ef2bca8) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:1375
#7 0x000055b80ce32952 in gistplacetopage (rel=0x7f7a5705d668,
freespace=<optimized out>, giststate=giststate@entry=0x55b80ef2bca8,
buffer=1541, itup=itup@entry=0x7fffc143a388, ntup=ntup@entry=1,
oldoffnum=0, newblkno=0x0, leftchildbuf=0, splitinfo=0x7fffc143a2c0,
markfollowright=1 '\001', heapRel=0x7f7a5705c658) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:295
#8 0x000055b80ce3341e in gistinserttuples
(state=state@entry=0x7fffc143a390,
stack=stack@entry=0x7fffc143a3b0, giststate=giststate@entry=0x55b80ef2bca8,
tuples=tuples@entry=0x7fffc143a388, ntup=ntup@entry=1,
oldoffnum=oldoffnum@entry=0, leftchild=0, rightchild=0,
unlockbuf=0 '\000', unlockleftchild=0 '\000') at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:1221
#9 0x000055b80ce3382a in gistinserttuple (oldoffnum=0,
tuple=0x55b80ef21ce8, giststate=0x55b80ef2bca8, stack=0x7fffc143a3b0,
state=0x7fffc143a390) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:1180
#10 gistdoinsert (r=r@entry=0x7f7a5705d668,
itup=itup@entry=0x55b80ef21ce8,
freespace=<optimized out>, giststate=0x55b80ef2bca8, heapRel=<optimized
out>) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gist.c:837
#11 0x000055b80ce3cd11 in gistBuildCallback
(index=index@entry=0x7f7a5705d668,
htup=htup@entry=0x55b80eec6f80, values=values@entry=0x7fffc143a590,
isnull=isnull@entry=0x7fffc143a8e0 "", tupleIsAlive=tupleIsAlive@entry=1
'\001', state=state@entry=0x7fffc143a9a0)
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistbuild.c:488
#12 0x000055b80ceb15e7 in IndexBuildHeapRangeScan
(heapRelation=heapRelation@entry=0x7f7a5705c658,
indexRelation=indexRelation@entry=0x7f7a5705d668,
indexInfo=indexInfo@entry=0x55b80eec6378,
allow_sync=allow_sync@entry=1 '\001', anyvisible=anyvisible@entry=0 '\000',
start_blockno=start_blockno@entry=0, numblocks=4294967295,
callback=0x55b80ce3cc80 <gistBuildCallback>, callback_state=0x7fffc143a9a0)
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:2701
#13 0x000055b80ceb1b0c in IndexBuildHeapScan
(heapRelation=heapRelation@entry=0x7f7a5705c658,
indexRelation=indexRelation@entry=0x7f7a5705d668,
indexInfo=indexInfo@entry=0x55b80eec6378,
allow_sync=allow_sync@entry=1 '\001',
callback=callback@entry=0x55b80ce3cc80 <gistBuildCallback>,
callback_state=callback_state@entry=0x7fffc143a9a0) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:2271
#14 0x000055b80ce3d380 in gistbuild (heap=0x7f7a5705c658,
index=0x7f7a5705d668, indexInfo=0x55b80eec6378) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/access/gist/gistbuild.c:207
#15 0x000055b80ceb2923 in index_build
(heapRelation=heapRelation@entry=0x7f7a5705c658,
indexRelation=indexRelation@entry=0x7f7a5705d668,
indexInfo=indexInfo@entry=0x55b80eec6378,
isprimary=isprimary@entry=0 '\000', isreindex=isreindex@entry=0 '\000')
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:2132
#16 0x000055b80ceb42b9 in index_create
(heapRelation=heapRelation@entry=0x7f7a5705c658,
indexRelationName=indexRelationName@entry=0x55b80eec6738
"test_table_geom_idx", indexRelationId=599550, indexRelationId@entry=0,
relFileNode=<optimized out>,
indexInfo=indexInfo@entry=0x55b80eec6378,
indexColNames=indexColNames@entry=0x55b80eec7388, accessMethodObjectId=783,
tableSpaceId=1663, collationObjectId=0x55b80eec73d0,
classObjectId=0x55b80eec73e8, coloptions=0x55b80eec7400, reloptions=0,
isprimary=0 '\000',
isconstraint=0 '\000', deferrable=0 '\000', initdeferred=0
'\000', allow_system_table_mods=0 '\000', skip_build=0 '\000', concurrent=0
'\000', is_internal=0 '\000', if_not_exists=0 '\000')
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/catalog/index.c:1133
#17 0x000055b80cf518b0 in DefineIndex (relationId=<optimized out>,
relationId@entry=534024, stmt=stmt@entry=0x55b80eec6768,
indexRelationId=indexRelationId@entry=0, is_alter_table=is_alter_table@entry=0
'\000', check_rights=check_rights@entry=1 '\001',
check_not_in_use=check_not_in_use@entry=1 '\001', skip_build=0
'\000', quiet=0 '\000') at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/commands/indexcmds.c:682
#18 0x000055b80d0e2f80 in ProcessUtilitySlow
(pstate=pstate@entry=0x55b80eec6218,
pstmt=pstmt@entry=0x55b80ee123c0,
queryString=queryString@entry=0x55b80ee11358 "CREATE INDEX
test_table_geom_idx ON public.test_table USING gist(st_intersection
gist_geometry_ops_nd) TABLESPACE pg_default;",
context=context@entry=PROCESS_UTILITY_TOPLEVEL,
params=params@entry=0x0,
queryEnv=queryEnv@entry=0x0, completionTag=0x7fffc143b3f0 "",
dest=0x55b80ee124a0) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/utility.c:1336
#19 0x000055b80d0e1f87 in standard_ProcessUtility
(pstmt=0x55b80ee123c0, queryString=0x55b80ee11358 "CREATE INDEX
test_table_geom_idx ON public.test_table USING gist(st_intersection
gist_geometry_ops_nd) TABLESPACE pg_default;",
context=PROCESS_UTILITY_TOPLEVEL,
params=0x0, queryEnv=0x0, dest=0x55b80ee124a0,
completionTag=0x7fffc143b3f0 "") at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/utility.c:931
#20 0x000055b80d0defab in PortalRunUtility (portal=0x55b80edab5a8,
pstmt=0x55b80ee123c0, isTopLevel=<optimized out>,
setHoldSnapshot=<optimized out>, dest=<optimized out>,
completionTag=0x7fffc143b3f0 "")
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/pquery.c:1178
#21 0x000055b80d0dfa98 in PortalRunMulti
(portal=portal@entry=0x55b80edab5a8,
isTopLevel=isTopLevel@entry=1 '\001', setHoldSnapshot=setHoldSnapshot@entry=0
'\000', dest=dest@entry=0x55b80ee124a0, altdest=altdest@entry=0x55b80ee124a0,

completionTag=completionTag@entry=0x7fffc143b3f0 "") at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/pquery.c:1331
#22 0x000055b80d0e0805 in PortalRun
(portal=portal@entry=0x55b80edab5a8,
count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=1
'\001', run_once=run_once@entry=1 '\001', dest=dest@entry=0x55b80ee124a0,
altdest=altdest@entry=0x55b80ee124a0,
completionTag=0x7fffc143b3f0 "") at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/pquery.c:799
#23 0x000055b80d0dc2bc in exec_simple_query
(query_string=0x55b80ee11358 "CREATE INDEX test_table_geom_idx ON
public.test_table USING gist(st_intersection gist_geometry_ops_nd)
TABLESPACE pg_default;")
at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/postgres.c:1122
#24 0x000055b80d0dd7e8 in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x55b80edb10c0, dbname=0x55b80edb0f88 "test_crash",
username=<optimized out>) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/tcop/postgres.c:4128
#25 0x000055b80ce1187e in BackendRun (port=0x55b80eda76a0) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:4408
#26 BackendStartup (port=0x55b80eda76a0) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:4080
#27 ServerLoop () at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:1756
#28 0x000055b80d06b819 in PostmasterMain (argc=5, argv=<optimized
out>) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/postmaster/postmaster.c:1364
#29 0x000055b80ce12c75 in main (argc=5, argv=0x55b80ed5a850) at
/build/postgresql-10-0Kn02a/postgresql-10-10.12/build/../src/backend/main/main.c:228
(gdb) c
Continuing.

7. When I press c in gdb secend time then in first psql I received:
UWAGA: indeks "test_table_geom_idx" nie istnieje, pominięto
DROP INDEX
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

8. When I try to continue or bt in gdb I received:
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt
No stack.
(gdb) c
The program is not being run.
(gdb)

Hi everyone,

I am facing what seems to be the exact same problem, but with more
recent versions of both PostgreSQL and PostGIS

SELECT version();
PostgreSQL 12.2 (Ubuntu 12.2-4) on x86_64-pc-linux-gnu, compiled by gcc
(Ubuntu 9.3.0-8ubuntu1) 9.3.0, 64-bit

SELECT postgis_full_version();
POSTGIS="3.0.0 r17983" [EXTENSION] PGSQL="120" GEOS="3.8.0-CAPI-1.13.1 "
PROJ="6.3.1" LIBXML="2.9.4" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3"
WAGYU="0.4.3 (Internal)"

I have been able to obtain a stacktrace with the PostGIS symbols, using
`bt full' in GDB on the core dump.

#0  pfree (pointer=0x7fdd15acc1a8) at
./build/../src/backend/utils/mmgr/mcxt.c:1035
        context = 0x4028000d051c0000
#1  0x00007fdd14c3a3c8 in gserialized_gist_picksplit_addlist
(list=0x5639c5e19858, box_union=box_union@entry=0x5639c5e18f28,
box_current=box_current@entry=0x7fdd15acc8e8, pos=pos@entry=0x5639c5e18ee8,
    num=num@entry=26) at gserialized_gist_nd.c:1378
No locals.
#2  0x00007fdd14c3ba23 in gserialized_gist_picksplit (fcinfo=<optimized
out>) at gserialized_gist_nd.c:1722
        center = <optimized out>
        avgCenter = 0x5639c5e19c78
        entryvec = 0x5639c5e16cb8
        v = 0x7fff44b6f690
        i = <optimized out>
        box_union = 0x5639c5e18f08
        list = 0x5639c5e12be0
        pos = 0x5639c5e18ed8
        box_pageunion = 0x5639c5e10e00
        box_current = 0x7fdd15acc8e8
        direction = -1
        all_entries_equal = <optimized out>
        max_offset = 168
        nbytes = 340
        ndims_pageunion = 3
        d = <optimized out>
        posmin = 169
        __func__ = "gserialized_gist_picksplit"
#3  0x00005639c41fba99 in FunctionCall2Coll
(flinfo=flinfo@entry=0x5639c5de3490, collation=<optimized out>,
arg1=arg1@entry=94806133009592, arg2=arg2@entry=140734346229392)
    at ./build/../src/backend/utils/fmgr/fmgr.c:1162
        fcinfodata = {fcinfo = {flinfo = 0x5639c5de3490, context = 0x0,
resultinfo = 0x0, fncollation = 100, isnull = false, nargs = 2, args =
0x7fff44b6f4a0},
          fcinfo_data = "\220\064\336\305\071V", '\000' <repeats 18
times>,
"d\000\000\000\000V\002\000\270l\341\305\071V\000\000\000>\341\303\071V\000\000\220\366\266D\377\177\000\000\000\000\000\000\000\000\000"}
        fcinfo = 0x7fff44b6f480
        result = <optimized out>
        __func__ = "FunctionCall2Coll"
        __errno_location = <optimized out>
#4  0x00005639c3e1c4ab in gistUserPicksplit (len=168,
giststate=0x5639c5de1668, itup=0x5639c5e10f20, v=0x7fff44b6f690,
attno=0, entryvec=0x5639c5e16cb8, r=0x7fdd14d30ee8)
    at ./build/../src/backend/access/gist/gistsplit.c:433
        sv = 0x7fff44b6f690
        sv = <optimized out>
        __func__ = "gistUserPicksplit"
        __errno_location = <optimized out>
        NumDontCare = <optimized out>
        toMove = <optimized out>
#5  gistSplitByKey (r=r@entry=0x7fdd14d30ee8,
page=page@entry=0x7fdd15acad00 "", itup=itup@entry=0x5639c5e10f20,
len=168, giststate=giststate@entry=0x5639c5de1668,
v=v@entry=0x7fff44b6f690, attno=0)
    at ./build/../src/backend/access/gist/gistsplit.c:697
        entryvec = 0x5639c5e16cb8
        offNullTuples = <optimized out>
        nOffNullTuples = <optimized out>
        i = <optimized out>
#6  0x00005639c3e1202b in gistSplit (r=0x7fdd14d30ee8,
page=0x7fdd15acad00 "", itup=0x5639c5e10f20, len=<optimized out>,
giststate=0x5639c5de1668) at ./build/../src/backend/access/gist/gist.c:1451
        lvectup = <optimized out>
        rvectup = <optimized out>
        v = {splitVector = {spl_left = 0x1, spl_nleft = 16384,
spl_ldatum = 94806132985400, spl_ldatum_exists = false, spl_right =
0x3fc5555555555515, spl_nright = -42257124, spl_rdatum = 0,
            spl_rdatum_exists = false}, spl_lattr = {94806132985400,
140587513876200, 0, 3155123322044284928, 140734346229776,
140734346229632, 94806132985264, 140734346229560, 140734346229552,
140587513396116,
            4585845765077098099, 4607175408094817544,
4604108167824115460, 4604952369619992743, 140734346229616,
94806132985296, 140734346229696, 140734346230064, 140734346230432,
140587513413085, 0,
            140587513122282, 4604103549945663722, 4583146448194962646,
4604952369619992743, 140587513165489, 8, 94806132985256, 4,
94806132985296, 8, 0}, spl_lisnull = {true, false <repeats 31 times>},
          spl_rattr = {0, 0, 0, 3155123322047568640, 140734346229856,
94806132985296, 140734346230064, 140587523272732, 140734346230432,
94806099337124, 94806132985296, 140587513413356, 140587513888440,
140734346230030, 140734346231152, 140734346230064, 94802813124608, 0,
140587513888652, 140734346230032, 94806132985392, 140587513888652,
140587513888440, 140734346230064, 140734346230384, 94806099343697, 0,
94806132984880, 1344, 844, 140734346230632, 140587528137984},
spl_risnull = {true, 249, 182, 68, 255, 127, false, false, 97, 225, 33,
196, 57, 86, false, false, 48, 249, 182, 68, 255, 127, false, false,
204, 249, 182, 68, 255, 127, false, false}, spl_dontcare = 0x1}
        i = <optimized out>
        res = 0x0
        __func__ = "gistSplit"
#7  0x00005639c3e123f3 in gistplacetopage (rel=0x7fdd14d30ee8,
freespace=<optimized out>, giststate=giststate@entry=0x5639c5de1668,
buffer=844, itup=itup@entry=0x7fff44b6fb68, ntup=ntup@entry=1,
oldoffnum=0, newblkno=0x0, leftchildbuf=0, splitinfo=0x7fff44b6fab0,
markfollowright=true, heapRel=0x7fdd14d2e118, is_build=true) at
./build/../src/backend/access/gist/gist.c:299
        itvec = <optimized out>
        dist = 0x0
        oldnsn = 0
        npage = <optimized out>
        tlen = 168
        ptr = <optimized out>
        oldrlink = 4294967295
        rootpg = {block = {blkno = 350328448, num = 32733}, list =
0x6066817f, lenlist = 1152842416, itup = 0x5639c40afe0a
<ReadBuffer_common+1258>, page = 0x7fff44b6fae7 "", buffer = 0, next = 0x70}
        is_rootsplit = false
        blkno = 601
        page = 0x7fdd15acad00 ""
        is_leaf = true
        recptr = <optimized out>
        i = <optimized out>
        is_split = <optimized out>
        __func__ = "gistplacetopage"
#8  0x00005639c3e12f1e in gistinserttuples
(state=state@entry=0x7fff44b6fba0, stack=stack@entry=0x5639c5e10ed0,
giststate=giststate@entry=0x5639c5de1668,
tuples=tuples@entry=0x7fff44b6fb68, ntup=ntup@entry=1,
oldoffnum=oldoffnum@entry=0, leftchild=0, rightchild=0, unlockbuf=false,
unlockleftchild=false) at ./build/../src/backend/access/gist/gist.c:1269
        splitinfo = 0x0
        is_split = <optimized out>
#9  0x00005639c3e1331e in gistinserttuple (oldoffnum=0, tuple=<optimized
out>, giststate=0x5639c5de1668, stack=0x5639c5e10ed0,
state=0x7fff44b6fba0) at ./build/../src/backend/access/gist/gist.c:1222
No locals.
#10 gistdoinsert (r=r@entry=0x7fdd14d30ee8,
itup=itup@entry=0x5639c5e10e30, freespace=<optimized out>,
giststate=0x5639c5de1668, heapRel=<optimized out>,
is_build=is_build@entry=true) at
./build/../src/backend/access/gist/gist.c:876
        iid = <optimized out>
        idxtuple = <optimized out>
        firststack = {blkno = 0, buffer = 211, page = 0x7fdd155d8d00
"", lsn = 1, retry_from_parent = false, downlinkoffnum = 0, parent = 0x0}
        stack = 0x5639c5e10ed0
        state = {r = 0x7fdd14d30ee8, heapRel = 0x7fdd14d2e118,
freespace = 819, is_build = true, stack = 0x5639c5e10ed0}
        xlocked = <optimized out>
        __func__ = "gistdoinsert"
#11 0x00005639c3e1dc91 in gistBuildCallback
(index=index@entry=0x7fdd14d30ee8, htup=htup@entry=0x5639c5dd0a88,
values=values@entry=0x7fff44b6fd90, isnull=isnull@entry=0x7fff44b6fd70,
tupleIsAlive=tupleIsAlive@entry=true, state=state@entry=0x7fff44b70170)
at ./build/../src/backend/access/gist/gistbuild.c:489
        buildstate = 0x7fff44b70170
        itup = 0x5639c5e10e30
        oldCtx = 0x5639c5d3f820
#12 0x00005639c3e35e6c in heapam_index_build_range_scan
(heapRelation=0x7fdd14d2e118, indexRelation=0x7fdd14d30ee8,
indexInfo=0x5639c5d3feb8, allow_sync=<optimized out>, anyvisible=false,
progress=true, start_blockno=0, numblocks=4294967295,
callback=0x5639c3e1dc00 <gistBuildCallback>,
callback_state=0x7fff44b70170, scan=0x5639c5dd0a38) at
./build/../src/backend/access/heap/heapam_handler.c:1664
        tupleIsAlive = true
        hscan = 0x5639c5dd0a38
        is_system_catalog = false
        checking_uniqueness = false
        heapTuple = 0x5639c5dd0a88
        values = {140587523272732, 0, 94806132784048, 94806132804896,
140587513896984, 140587720357032, 94806132765608, 140587712194344,
140734346231536, 0, 140587720357008, 140734346231648, 94806105258868,
94806105258868, 140734346231536, 140734346231292, 94806132765608,
3086255563502438562, 18446744073709551472, 94806132784048,
94806132804896, 3155123322047568640, 8744187018653911202, 128,
94806105414899, 94806105414899, 140734346231552, 94806102306725,
140734346231488, 0, 1, 16384}
        isnull = {false, 253, 182, 68, 255, 127, false, false, false,
27, 50, 225, 241, 63, 201, 43, true, 64, false, false, 231, 4, false,
false, 96, 255, 182, 68, 255, 127, false, false}
        reltuples = 66513
        predicate = 0x0
        slot = 0x5639c5d41488
        estate = 0x5639c5e12d70
        econtext = 0x5639c5e12f80
        snapshot = 0x5639c449e3e0 <SnapshotAnyData>
        need_unregister_snapshot = false
        OldestXmin = <optimized out>
        previous_blkno = 2590
        root_blkno = 2590
        root_offsets = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 0 <repeats 263
times>}
        __func__ = "heapam_index_build_range_scan"
#13 0x00005639c3e1e2c5 in table_index_build_scan (scan=0x0,
callback_state=0x7fff44b70170, callback=0x5639c3e1dc00
<gistBuildCallback>, progress=true, allow_sync=true,
index_info=0x5639c5d3feb8, index_rel=0x7fdd14d30ee8,
table_rel=0x7fdd14d2e118) at ./build/../src/include/access/tableam.h:1522
No locals.
#14 gistbuild (heap=0x7fdd14d2e118, index=0x7fdd14d30ee8,
indexInfo=0x5639c5d3feb8) at
./build/../src/backend/access/gist/gistbuild.c:196
        result = <optimized out>
        reltuples = <optimized out>
        buildstate = {indexrel = 0x7fdd14d30ee8, heaprel =
0x7fdd14d2e118, giststate = 0x5639c5de1668, indtuples = 66512,
indtuplesSize = 2366816, freespace = 819, gfbb = 0x0, parentMap = 0x0,
bufferingMode = GIST_BUFFERING_AUTO}
        buffer = 211
        page = <optimized out>
        oldcxt = 0x5639c5d3f820
        fillfactor = <optimized out>
        __func__ = "gistbuild"
#15 0x00005639c3e9be20 in index_build
(heapRelation=heapRelation@entry=0x7fdd14d2e118,
indexRelation=indexRelation@entry=0x7fdd14d30ee8,
indexInfo=indexInfo@entry=0x5639c5d3feb8,
isreindex=isreindex@entry=false, parallel=parallel@entry=true) at
./build/../src/backend/catalog/index.c:2902
        stats = <optimized out>
        save_userid = 10
        save_sec_context = 0
        save_nestlevel = 2
        __func__ = "index_build"
#16 0x00005639c3e9d2a1 in index_create
(heapRelation=heapRelation@entry=0x7fdd14d2e118,
indexRelationName=indexRelationName@entry=0x5639c5d41698
"people_person_coordinates_id", indexRelationId=<optimized out>,
indexRelationId@entry=0, parentIndexRelid=parentIndexRelid@entry=0,
parentConstraintId=parentConstraintId@entry=0, relFileNode=<optimized
out>, indexInfo=<optimized out>, indexColNames=<optimized out>,
accessMethodObjectId=<optimized out>, tableSpaceId=<optimized out>,
collationObjectId=<optimized out>, classObjectId=<optimized out>,
coloptions=<optimized out>, reloptions=<optimized out>, flags=<optimized
out>, constr_flags=<optimized out>, allow_system_table_mods=<optimized
out>, is_internal=<optimized out>, constraintId=<optimized out>) at
./build/../src/backend/catalog/index.c:1221
        heapRelationId = <optimized out>
        pg_class = <optimized out>
        indexRelation = 0x7fdd14d30ee8
        indexTupDesc = 0x5639c5d417e8
        shared_relation = <optimized out>
        mapped_relation = <optimized out>
        is_exclusion = <optimized out>
        namespaceId = <optimized out>
        i = <optimized out>
        relpersistence = <optimized out>
        isprimary = <optimized out>
        invalid = <optimized out>
        concurrent = <optimized out>
        partitioned = <optimized out>
        relkind = <optimized out>
        relfrozenxid = 0
        relminmxid = 0
        __func__ = "index_create"
#17 0x00005639c3f36f2e in DefineIndex
(relationId=relationId@entry=20147, stmt=stmt@entry=0x5639c5d3fba0,
indexRelationId=indexRelationId@entry=0,
parentIndexId=parentIndexId@entry=0,
parentConstraintId=parentConstraintId@entry=0,
is_alter_table=is_alter_table@entry=false, check_rights=true,
check_not_in_use=true, skip_build=false, quiet=false) at
./build/../src/backend/commands/indexcmds.c:1005
        concurrent = <optimized out>
        indexRelationName = 0x5639c5d41698 "people_person_coordinates_id"
        accessMethodName = <optimized out>
        typeObjectId = <optimized out>
        collationObjectId = <optimized out>
        classObjectId = <optimized out>
        accessMethodId = 783
        namespaceId = <optimized out>
        tablespaceId = 0
        createdConstraintId = 0
        indexColNames = 0x5639c5dd6928
        allIndexParams = <optimized out>
        rel = 0x7fdd14d2e118
        tuple = <optimized out>
        accessMethodForm = <optimized out>
        amRoutine = <optimized out>
        amcanorder = <optimized out>
        amoptions = <optimized out>
        partitioned = <optimized out>
        reloptions = 0
        coloptions = <optimized out>
        indexInfo = <optimized out>
        flags = <optimized out>
        constr_flags = <optimized out>
        numberOfAttributes = <optimized out>
        numberOfKeyAttributes = 1
        limitXmin = <optimized out>
        address = <optimized out>
        heaprelid = {relId = 3319621704, dbId = 22073}
        heaplocktag = <optimized out>
        lockmode = 5
        snapshot = <optimized out>
        save_nestlevel = -1
        i = <optimized out>
        __func__ = "DefineIndex"
#18 0x00005639c40e415f in ProcessUtilitySlow
(pstate=pstate@entry=0x5639c5d3f930, pstmt=pstmt@entry=0x5639c5cf8f78,
queryString=queryString@entry=0x5639c5cf7fd0 "CREATE INDEX
people_person_coordinates_id ON public.people_person USING gist
(coordinates);", context=context@entry=PROCESS_UTILITY_TOPLEVEL,
params=params@entry=0x0, queryEnv=queryEnv@entry=0x0,
completionTag=0x7fff44b70d60 "", dest=0x5639c5cf9058) at
./build/../src/backend/tcop/utility.c:1372
        stmt = 0x5639c5d3fba0
        relid = 20147
        lockmode = <optimized out>
        save_exception_stack = 0x7fff44b70c20
        save_context_stack = 0x0
        local_sigjmp_buf = {{__jmpbuf = {140734346235232,
8744187003067877538, 0, 94806131837944, 94806132128048, 94806131834832,
8744187003416004770, 3086257337499830434}, __mask_was_saved = 0,
__saved_mask = {__val = {0, 0, 2, 2, 94802813127573, 4, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0}}}}
        parsetree = 0x5639c5cf8bf8
        isTopLevel = true
        isCompleteQuery = true
        needCleanup = false
        commandCollected = false
        address = {classId = 3, objectId = 0, objectSubId = 3}
        secondaryObject = {classId = 0, objectId = 0, objectSubId = 0}
        __func__ = "ProcessUtilitySlow"
#19 0x00005639c40e2c7f in standard_ProcessUtility (pstmt=0x5639c5cf8f78,
queryString=0x5639c5cf7fd0 "CREATE INDEX people_person_coordinates_id ON
public.people_person USING gist (coordinates);",
context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
dest=0x5639c5cf9058, completionTag=0x7fff44b70d60 "") at
./build/../src/backend/tcop/utility.c:927
        parsetree = 0x5639c5cf8bf8
        isTopLevel = <optimized out>
        isAtomicContext = false
        pstate = 0x5639c5d3f930
        __func__ = "standard_ProcessUtility"
#20 0x00005639c40dfcb4 in PortalRunUtility (portal=0x5639c5d809d0,
pstmt=0x5639c5cf8f78, isTopLevel=<optimized out>,
setHoldSnapshot=<optimized out>, dest=0x5639c5cf9058,
completionTag=0x7fff44b70d60 "") at
./build/../src/backend/tcop/pquery.c:1175
        utilityStmt = <optimized out>
        snapshot = 0x5639c5d9d340
#21 0x00005639c40e0767 in PortalRunMulti
(portal=portal@entry=0x5639c5d809d0, isTopLevel=isTopLevel@entry=true,
setHoldSnapshot=setHoldSnapshot@entry=false,
dest=dest@entry=0x5639c5cf9058, altdest=altdest@entry=0x5639c5cf9058,
completionTag=completionTag@entry=0x7fff44b70d60 "") at
./build/../src/backend/tcop/pquery.c:1321
        pstmt = 0x5639c5cf8f78
        active_snapshot_set = false
        stmtlist_item = 0x5639c5cf9008
#22 0x00005639c40e13ae in PortalRun (portal=portal@entry=0x5639c5d809d0,
count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true,
run_once=run_once@entry=true, dest=dest@entry=0x5639c5cf9058,
altdest=altdest@entry=0x5639c5cf9058, completionTag=0x7fff44b70d60 "")
at ./build/../src/backend/tcop/pquery.c:796
        save_exception_stack = 0x7fff44b70f90
        save_context_stack = 0x0
        local_sigjmp_buf = {{__jmpbuf = {1, 8744187003107723426,
94806132394448, 94806131838088, 2, 94806132394448, 8744187003021740194,
3086257336272603298}, __mask_was_saved = 0, __saved_mask = {__val = {0,
140736010536557, 94806105313453, 94806132406008, 94802813124609,
94806132402800, 64, 94806131834560, 112, 94806131838088, 2,
140734346235120, 94806103678836, 140734346235152, 2, 94806104811427}}}}
        result = <optimized out>
        nprocessed = <optimized out>
        saveTopTransactionResourceOwner = 0x5639c5d46578
        saveTopTransactionContext = 0x5639c5d9d200
        saveActivePortal = 0x0
        saveResourceOwner = 0x5639c5d46578
        savePortalContext = 0x0
        saveMemoryContext = 0x5639c5d9d200
        __func__ = "PortalRun"
#23 0x00005639c40dd257 in exec_simple_query (query_string=0x5639c5cf7fd0
"CREATE INDEX people_person_coordinates_id ON public.people_person USING
gist (coordinates);") at ./build/../src/backend/tcop/postgres.c:1215
        parsetree = 0x5639c5cf8c88
        portal = 0x5639c5d809d0
        snapshot_set = <optimized out>
        commandTag = <optimized out>
        completionTag =
"\000\r\267D\377\177\000\000\000\000\000\000\000\000\000\000\240\r\267D\377\177\000\000\f\030\273D\377\177\000\000\344\220\302^\000\000\000\000\001\000\000\000\000\000\000\000\320\177\317\305\071V\000\000\060\017\267D\377\177\000"
        querytree_list = <optimized out>
        plantree_list = <optimized out>
        receiver = <optimized out>
        format = 0
        dest = DestRemote
        oldcontext = <optimized out>
        parsetree_list = 0x5639c5cf8cd8
        parsetree_item = 0x5639c5cf8cb8
        save_log_statement_stats = false
        was_logged = false
        use_implicit_block = false
        msec_str =
"\000\r\267D\377\177\000\000\000\000\000\000\000\000\000\000\240\r\267D\377\177\000\000\f\030\273D\377\177\000"
        __func__ = "exec_simple_query"
#24 0x00005639c40deb6a in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x5639c5d44b08, dbname=<optimized out>,
username=<optimized out>) at ./build/../src/backend/tcop/postgres.c:4247
        query_string = 0x5639c5cf7fd0 "CREATE INDEX
people_person_coordinates_id ON public.people_person USING gist
(coordinates);"
        firstchar = <optimized out>
        input_message = {data = 0x5639c5cf7fd0 "CREATE INDEX
people_person_coordinates_id ON public.people_person USING gist
(coordinates);", len = 92, maxlen = 1024, cursor = 92}
        local_sigjmp_buf = {{__jmpbuf = {1, 8744187002696681634,
140734346235728, 1, 94806132148664, 0, 8744187003080460450,
3086257350977570978}, __mask_was_saved = 1, __saved_mask = {__val = {0,
140734346235952, 94806103782045, 140734346239683, 140734346239642,
140734346239954, 0, 139637976727552, 3155123322047568640,
94806131810240, 3155123322047568640, 140734346236176, 94806103782259,
206158430256, 140734346236200, 140734346236000}}}}
        send_ready_for_query = false
        disable_idle_in_transaction_timeout = false
        __func__ = "PostgresMain"
#25 0x00005639c4069b6b in BackendRun (port=0x5639c5d40cd0,
port=0x5639c5d40cd0) at ./build/../src/backend/postmaster/postmaster.c:4437
        av = 0x5639c5d44b08
        maxac = <optimized out>
        ac = 1
        i = 1
        av = <optimized out>
        maxac = <optimized out>
        ac = <optimized out>
        i = <optimized out>
        __func__ = "BackendRun"
        __errno_location = <optimized out>
        __errno_location = <optimized out>
        __errno_location = <optimized out>
#26 BackendStartup (port=0x5639c5d40cd0) at
./build/../src/backend/postmaster/postmaster.c:4128
        bn = <optimized out>
        pid = <optimized out>
        bn = <optimized out>
        pid = <optimized out>
        __func__ = "BackendStartup"
        __errno_location = <optimized out>
        __errno_location = <optimized out>
        save_errno = <optimized out>
        __errno_location = <optimized out>
        __errno_location = <optimized out>
#27 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1704
        port = 0x5639c5d40cd0
        i = <optimized out>
        rmask = {fds_bits = {16, 0 <repeats 15 times>}}
        selres = <optimized out>
        now = <optimized out>
        readmask = {fds_bits = {24, 0 <repeats 15 times>}}
        nSockets = 5
        last_lockfile_recheck_time = 1589809339
        last_touch_time = 1589809279
        __func__ = "ServerLoop"
#28 0x00005639c406aa99 in PostmasterMain (argc=5, argv=<optimized out>)
at ./build/../src/backend/postmaster/postmaster.c:1377
        opt = <optimized out>
        status = <optimized out>
        userDoption = <optimized out>
        listen_addr_saved = <optimized out>
        i = <optimized out>
        output_config_variable = <optimized out>
        __func__ = "PostmasterMain"
#29 0x00005639c3df1b88 in main (argc=5, argv=0x5639c5cf1ee0) at
./build/../src/backend/main/main.c:228
        do_check_root = <optimized out>

I'm also trying to file a report with PostGIS (currently waiting for my
UserID), but in the meantime, I'd be grateful if you had any ideas or
hints on where to go from here.

--
Arthur Cheysson
Developper for la France insoumise

Arthur Cheysson <site@lafranceinsoumise.fr> writes:

I am facing what seems to be the exact same problem, but with more
recent versions of both PostgreSQL and PostGIS

Given that stack trace, you need to be reporting this to the PostGIS
folk, not here.

They'll likely ask you for a reproducible test case, too ...

regards, tom lane

I filed a bug with PostGIS, and I think I found the origin of the
segfault in my case: this segfault seems to happen whenever there are a
few empty points (with [nan, nan] as coordinates) in my column, in a
non-deterministic manner.

https://trac.osgeo.org/postgis/attachment/ticket/4691/

Regards,
Arthur

Le 18/05/2020 à 18:22, Tom Lane a écrit :