Обсуждение: BUG #16283: crash on create index segmentation fault
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.
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.
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&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
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&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
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
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:
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 : > 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