#4912 closed defect (fixed)
Postgres 11+ crashes with segmentation fault 11 when using SET STORAGE EXTERNAL on a `geographic` column
Reported by: | progm | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.1.5 |
Component: | postgis | Version: | 3.1.x |
Keywords: | Cc: |
Description
Postgres 11+ crashes with segmentation fault 11
when using SET STORAGE EXTERNAL
on a geographic
column.
Being more specific, the segmentation fault happens when you switch to storage external a table containing a certain amount of data.
How to reproduce with docker (I've tested on macOS):
$ docker run --name postgis -p 5432:5432 -e POSTGRES_HOST_AUTH_METHOD=trust -e POSTGRES_PASSWORD=password postgis/postgis:11-3.1 $ psql -U postgres -h 127.0.0.1 postgres=# CREATE TABLE areas (id serial, geog geography(Multipolygon, 4326)); postgres=# insert into areas (id, geog) select i, ST_GeomFromText('MULTIPOLYGON (((11.174038669077522 44.00998460379789, 11.169693264583247 43.979730968523256, 11.08178331755044 43.970801288841, 11.011641246672006 44.00374236407625, 11.040369198606385 44.03420070463533, 11.049434195204165 44.09024166231109, 11.093226216052033 44.09445494894457, 11.107143581001756 44.05024384632795, 11.133566054440559 44.03986705890006, 11.125261503629277 44.022849011558975, 11.174038669077522 44.00998460379789)))') as geog from generate_series(1,1000) i; postgres=# CREATE INDEX testing_idx ON areas USING GIST (geog); postgres=# ALTER TABLE areas ALTER COLUMN geog SET STORAGE EXTERNAL; postgres=# VACUUM FULL ANALYZE areas;
However, this seems to happen also if you switch to "storage external" first and you INSERT
the data later.
I've tried exactly the same example with postgres 10 with postgis 3.1 and it works correctly with no segmentation fault.
Maybe it's a regression with postgres 11+ (you can replicate it with 12 and 13 as well).
Let me know if you need any further information.
Change History (8)
comment:1 by , 4 years ago
Milestone: | PostGIS 3.1.2 → 3.1.3 |
---|
comment:2 by , 4 years ago
Milestone: | 3.1.3 → PostGIS 3.1.3 |
---|
comment:4 by , 3 years ago
Thanks for researching the PgSQL version. I can replicate your result, but the stack trace doesn't provide any obvious clues, except to show the problem is in the rebuild of the index that gets triggered on a REINDEX
or a VACUUM FULL
or even an UPDATE area SET geom = geom
. The failure is in the index building code, but annoyingly not always in the same place!
comment:5 by , 3 years ago
Also to note, I've tried a number of times to replicate without PostGIS. Trying with a tsvector column for example, but no luck.
comment:6 by , 3 years ago
Milestone: | PostGIS 3.1.4 → PostGIS 3.1.5 |
---|
@pramsey did you try with the PostgreSQL geometry types? I would assume that is a closer proxy to PostGIS.
Milestone renamed