From marco at boeringa.demon.nl Tue Dec 2 10:57:53 2025 From: marco at boeringa.demon.nl (Marco Boeringa) Date: Tue, 2 Dec 2025 19:57:53 +0100 Subject: Problem with ST_NRings Message-ID: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> Hi, As part of a larger workflow, I am using a custom PostgreSQL function that depends on ST_NRings, and is used to create a MATERIALIZED VIEW. This has worked flawlessly until recently. I now ran into an issue with the error message below. Going over my own code calling the custom function that includes the ST_NRings call, I just cannot see any recent code change made by myself explaining this sudden error. This part of the code has been stable for quite a while. As input to the custom function, WGS1984 OpenStreetMap data is used, stored as? 'geometry' type. There are actually explicit type casts in the code as well, so even that part of the error message I cannot explain for now. My question: has there been any change to ST_NRings in a recent update of PostGIS (3.6.0 or 3.6.1?), that might explain this error? E.g. should the 'public' be in this error message at all, I would have expected "ERROR:? function st_nrings(geometry) does not exist"? Marco ERROR:? function st_nrings(public.geometry) does not exist LINE 8:? ? WHEN ST_NRings($1) = 1 THEN $1 ? ? ? ? ? ? ? ? ^ HINT:? No function matches the given name and argument types. You might need to add explicit type casts. From marco at boeringa.demon.nl Tue Dec 2 11:19:38 2025 From: marco at boeringa.demon.nl (Marco Boeringa) Date: Tue, 2 Dec 2025 20:19:38 +0100 Subject: Problem with ST_NRings In-Reply-To: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> References: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> Message-ID: <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> If I change the CREATE MATERIALIZED VIEW to CREATE TABLE, exactly the same SQL statement succeeds... Both modes used to work. My current setup is PostgreSQL 18.1 / PostGIS 3.6.1. Marco Op 2-12-2025 om 19:57 schreef Marco Boeringa: > Hi, > > As part of a larger workflow, I am using a custom PostgreSQL function > that depends on ST_NRings, and is used to create a MATERIALIZED VIEW. > > This has worked flawlessly until recently. I now ran into an issue > with the error message below. Going over my own code calling the > custom function that includes the ST_NRings call, I just cannot see > any recent code change made by myself explaining this sudden error. > This part of the code has been stable for quite a while. > > As input to the custom function, WGS1984 OpenStreetMap data is used, > stored as? 'geometry' type. There are actually explicit type casts in > the code as well, so even that part of the error message I cannot > explain for now. > > My question: has there been any change to ST_NRings in a recent update > of PostGIS (3.6.0 or 3.6.1?), that might explain this error? E.g. > should the 'public' be in this error message at all, I would have > expected "ERROR:? function st_nrings(geometry) does not exist"? > > Marco > > ERROR:? function st_nrings(public.geometry) does not exist > LINE 8:? ? WHEN ST_NRings($1) = 1 THEN $1 > ? ? ? ? ? ? ? ? ^ > HINT:? No function matches the given name and argument types. You > might need to add explicit type casts. > From ewie at ewie.name Tue Dec 2 11:43:19 2025 From: ewie at ewie.name (Erik Wienhold) Date: Tue, 2 Dec 2025 20:43:19 +0100 Subject: Problem with ST_NRings In-Reply-To: <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> References: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> Message-ID: On 2025-12-02 20:19 +0100, Marco Boeringa wrote: > If I change the CREATE MATERIALIZED VIEW to CREATE TABLE, exactly the same > SQL statement succeeds... Both modes used to work. My current setup is > PostgreSQL 18.1 / PostGIS 3.6.1. > > Op 2-12-2025 om 19:57 schreef Marco Boeringa: > > As part of a larger workflow, I am using a custom PostgreSQL function > > that depends on ST_NRings, and is used to create a MATERIALIZED VIEW. > > > > This has worked flawlessly until recently. I now ran into an issue with > > the error message below. Going over my own code calling the custom > > function that includes the ST_NRings call, I just cannot see any recent > > code change made by myself explaining this sudden error. This part of > > the code has been stable for quite a while. > > > > As input to the custom function, WGS1984 OpenStreetMap data is used, > > stored as? 'geometry' type. There are actually explicit type casts in > > the code as well, so even that part of the error message I cannot > > explain for now. > > > > My question: has there been any change to ST_NRings in a recent update > > of PostGIS (3.6.0 or 3.6.1?), that might explain this error? E.g. should > > the 'public' be in this error message at all, I would have expected > > "ERROR:? function st_nrings(geometry) does not exist"? > > > > ERROR:? function st_nrings(public.geometry) does not exist > > LINE 8:? ? WHEN ST_NRings($1) = 1 THEN $1 > > ? ? ? ? ? ? ? ? ^ > > HINT:? No function matches the given name and argument types. You might > > need to add explicit type casts. Postgres runs REFRESH MATERIALIZED VIEW (and other maintenance commands) with a safe search_path since version 17 [1]. That also explains why you see type public.geometry instead of just geometry in the error message. You need to use the qualified function name public.ST_NRings in your custom function. Or change the search_path config of that function so that it no longer depends on the session search_path, e.g.: CREATE FUNCTION my_func(public.geometry) RETURNS int SET search_path = public, pg_catalog, pg_temp AS $$ SELECT ST_NRings($1); $$ LANGUAGE sql; [1] https://www.postgresql.org/docs/17/release-17.html#RELEASE-17-MIGRATION -- Erik Wienhold From marco at boeringa.demon.nl Tue Dec 2 12:35:47 2025 From: marco at boeringa.demon.nl (Marco Boeringa) Date: Tue, 2 Dec 2025 21:35:47 +0100 Subject: Problem with ST_NRings In-Reply-To: References: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> Message-ID: <8fc45369-fb86-412f-b6da-f9871b164d29@boeringa.demon.nl> Thanks Erik, Adding the search paths to the function definitions as you suggested, indeed fixed the issue. Still slightly puzzled that I didn't run into this before in the past year since upgrading to PG17/18, but I guess that I missed the particular configuration hitting this part of my code. Marco Op 2-12-2025 om 20:43 schreef Erik Wienhold: > On 2025-12-02 20:19 +0100, Marco Boeringa wrote: >> If I change the CREATE MATERIALIZED VIEW to CREATE TABLE, exactly the same >> SQL statement succeeds... Both modes used to work. My current setup is >> PostgreSQL 18.1 / PostGIS 3.6.1. >> >> Op 2-12-2025 om 19:57 schreef Marco Boeringa: >>> As part of a larger workflow, I am using a custom PostgreSQL function >>> that depends on ST_NRings, and is used to create a MATERIALIZED VIEW. >>> >>> This has worked flawlessly until recently. I now ran into an issue with >>> the error message below. Going over my own code calling the custom >>> function that includes the ST_NRings call, I just cannot see any recent >>> code change made by myself explaining this sudden error. This part of >>> the code has been stable for quite a while. >>> >>> As input to the custom function, WGS1984 OpenStreetMap data is used, >>> stored as? 'geometry' type. There are actually explicit type casts in >>> the code as well, so even that part of the error message I cannot >>> explain for now. >>> >>> My question: has there been any change to ST_NRings in a recent update >>> of PostGIS (3.6.0 or 3.6.1?), that might explain this error? E.g. should >>> the 'public' be in this error message at all, I would have expected >>> "ERROR:? function st_nrings(geometry) does not exist"? >>> >>> ERROR:? function st_nrings(public.geometry) does not exist >>> LINE 8:? ? WHEN ST_NRings($1) = 1 THEN $1 >>> ? ? ? ? ? ? ? ? ^ >>> HINT:? No function matches the given name and argument types. You might >>> need to add explicit type casts. > Postgres runs REFRESH MATERIALIZED VIEW (and other maintenance commands) > with a safe search_path since version 17 [1]. That also explains why > you see type public.geometry instead of just geometry in the error > message. > > You need to use the qualified function name public.ST_NRings in your > custom function. Or change the search_path config of that function so > that it no longer depends on the session search_path, e.g.: > > CREATE FUNCTION my_func(public.geometry) > RETURNS int > SET search_path = public, pg_catalog, pg_temp > AS $$ SELECT ST_NRings($1); $$ LANGUAGE sql; > > [1] https://www.postgresql.org/docs/17/release-17.html#RELEASE-17-MIGRATION > From lr at pcorp.us Tue Dec 2 19:38:28 2025 From: lr at pcorp.us (Regina Obe) Date: Tue, 2 Dec 2025 22:38:28 -0500 Subject: Problem with ST_NRings In-Reply-To: References: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> Message-ID: <000c01dc6406$4a94f650$dfbee2f0$@pcorp.us> > On 2025-12-02 20:19 +0100, Marco Boeringa wrote: > > If I change the CREATE MATERIALIZED VIEW to CREATE TABLE, exactly the > > same SQL statement succeeds... Both modes used to work. My current > > setup is PostgreSQL 18.1 / PostGIS 3.6.1. > > > > Op 2-12-2025 om 19:57 schreef Marco Boeringa: > > > As part of a larger workflow, I am using a custom PostgreSQL > > > function that depends on ST_NRings, and is used to create a > MATERIALIZED VIEW. > > > > > > This has worked flawlessly until recently. I now ran into an issue > > > with the error message below. Going over my own code calling the > > > custom function that includes the ST_NRings call, I just cannot see > > > any recent code change made by myself explaining this sudden error. > > > This part of the code has been stable for quite a while. > > > > > > As input to the custom function, WGS1984 OpenStreetMap data is used, > > > stored as 'geometry' type. There are actually explicit type casts > > > in the code as well, so even that part of the error message I cannot > > > explain for now. > > > > > > My question: has there been any change to ST_NRings in a recent > > > update of PostGIS (3.6.0 or 3.6.1?), that might explain this error? > > > E.g. should the 'public' be in this error message at all, I would > > > have expected > > > "ERROR: function st_nrings(geometry) does not exist"? > > > > > > ERROR: function st_nrings(public.geometry) does not exist LINE 8: > > > WHEN ST_NRings($1) = 1 THEN $1 > > > ^ > > > HINT: No function matches the given name and argument types. You > > > might need to add explicit type casts. > > Postgres runs REFRESH MATERIALIZED VIEW (and other maintenance > commands) with a safe search_path since version 17 [1]. That also explains > why you see type public.geometry instead of just geometry in the error > message. > > You need to use the qualified function name public.ST_NRings in your custom > function. Or change the search_path config of that function so that it no > longer depends on the session search_path, e.g.: > > CREATE FUNCTION my_func(public.geometry) > RETURNS int > SET search_path = public, pg_catalog, pg_temp > AS $$ SELECT ST_NRings($1); $$ LANGUAGE sql; > > [1] https://www.postgresql.org/docs/17/release-17.html#RELEASE-17- > MIGRATION > > -- > Erik Wienhold It would be better if you used the fully qualified name. Using search_path in a function crushes query performance. CREATE FUNCTION my_func(public.geometry) RETURNS int AS $$ SELECT public.ST_NRings($1); $$ LANGUAGE sql; From marco at boeringa.demon.nl Tue Dec 2 21:14:13 2025 From: marco at boeringa.demon.nl (Marco Boeringa) Date: Wed, 3 Dec 2025 06:14:13 +0100 Subject: Problem with ST_NRings In-Reply-To: <000c01dc6406$4a94f650$dfbee2f0$@pcorp.us> References: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> <000c01dc6406$4a94f650$dfbee2f0$@pcorp.us> Message-ID: Op 3-12-2025 om 04:38 schreef Regina Obe: >> On 2025-12-02 20:19 +0100, Marco Boeringa wrote: >>> If I change the CREATE MATERIALIZED VIEW to CREATE TABLE, exactly the >>> same SQL statement succeeds... Both modes used to work. My current >>> setup is PostgreSQL 18.1 / PostGIS 3.6.1. >>> >>> Op 2-12-2025 om 19:57 schreef Marco Boeringa: >>>> As part of a larger workflow, I am using a custom PostgreSQL >>>> function that depends on ST_NRings, and is used to create a >> MATERIALIZED VIEW. >>>> This has worked flawlessly until recently. I now ran into an issue >>>> with the error message below. Going over my own code calling the >>>> custom function that includes the ST_NRings call, I just cannot see >>>> any recent code change made by myself explaining this sudden error. >>>> This part of the code has been stable for quite a while. >>>> >>>> As input to the custom function, WGS1984 OpenStreetMap data is used, >>>> stored as 'geometry' type. There are actually explicit type casts >>>> in the code as well, so even that part of the error message I cannot >>>> explain for now. >>>> >>>> My question: has there been any change to ST_NRings in a recent >>>> update of PostGIS (3.6.0 or 3.6.1?), that might explain this error? >>>> E.g. should the 'public' be in this error message at all, I would >>>> have expected >>>> "ERROR: function st_nrings(geometry) does not exist"? >>>> >>>> ERROR: function st_nrings(public.geometry) does not exist LINE 8: >>>> WHEN ST_NRings($1) = 1 THEN $1 >>>> ^ >>>> HINT: No function matches the given name and argument types. You >>>> might need to add explicit type casts. >> Postgres runs REFRESH MATERIALIZED VIEW (and other maintenance >> commands) with a safe search_path since version 17 [1]. That also explains >> why you see type public.geometry instead of just geometry in the error >> message. >> >> You need to use the qualified function name public.ST_NRings in your custom >> function. Or change the search_path config of that function so that it no >> longer depends on the session search_path, e.g.: >> >> CREATE FUNCTION my_func(public.geometry) >> RETURNS int >> SET search_path = public, pg_catalog, pg_temp >> AS $$ SELECT ST_NRings($1); $$ LANGUAGE sql; >> >> [1] https://www.postgresql.org/docs/17/release-17.html#RELEASE-17- >> MIGRATION >> >> -- >> Erik Wienhold > It would be better if you used the fully qualified name. > Using search_path in a function crushes query performance. > > CREATE FUNCTION my_func(public.geometry) > RETURNS int > AS $$ SELECT public.ST_NRings($1); $$ LANGUAGE sql; Hi Regina, Thanks for that important warning about the performance aspect. However, do you possibly have any real world figures of how much of a difference this makes? Just doing an internet search on 'search_path' and 'performance' doesn't turn up much of relevant results for something that might be critical. I can see how a custom search path loaded with objects might turn a 'search' into a heavy operation, but I would expect PostgreSQL to at least cache some reference to the main functions and objects of system 'public', 'pg_catalog' and 'pg_temp' schema's, but maybe I am just naive here? Although I could change the code, having to add 'public' before each PostGIS function or class, would make my Python code assembling queries a lot less readable. Or is the performance issue you express concerns about mainly related to function definitions like in CREATE FUNCTION, which would make adjustment much more straightforward, as it would only require modifying the function definitions themselves, not all uses in SQL? Marco From lr at pcorp.us Tue Dec 2 21:56:00 2025 From: lr at pcorp.us (Regina Obe) Date: Wed, 3 Dec 2025 00:56:00 -0500 Subject: Problem with ST_NRings In-Reply-To: References: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> <000c01dc6406$4a94f650$dfbee2f0$@pcorp.us> Message-ID: <000d01dc6419$8152f5d0$83f8e170$@pcorp.us> > > It would be better if you used the fully qualified name. > > Using search_path in a function crushes query performance. > > > > CREATE FUNCTION my_func(public.geometry) > > RETURNS int > > AS $$ SELECT public.ST_NRings($1); $$ LANGUAGE sql; > > Hi Regina, > > Thanks for that important warning about the performance aspect. However, > do you possibly have any real world figures of how much of a difference this > makes? Just doing an internet search on 'search_path' and 'performance' > doesn't turn up much of relevant results for something that might be critical. I > can see how a custom search path loaded with objects might turn a 'search' > into a heavy operation, but I would expect PostgreSQL to at least cache some > reference to the main functions and objects of system 'public', 'pg_catalog' > and 'pg_temp' schema's, but maybe I am just naive here? > > Although I could change the code, having to add 'public' before each PostGIS > function or class, would make my Python code assembling queries a lot less > readable. Or is the performance issue you express concerns about mainly > related to function definitions like in CREATE FUNCTION, which would make > adjustment much more straightforward, as it would only require modifying the > function definitions themselves, not all uses in SQL? > > Marco Only pertains to putting it in functions variable settings. As I understand it changes the function then runs in isolation. I did this earlier on putting it in postgis search path function setting, cause that was faster than schema qualifying And it made queries so unbearably slow that I had to roll back that change. I thought maybe it would only affect index usage, but it even slowed down functions such as ST_Distance. Tom Lane described it here: https://www.postgresql.org/message-id/9914.1457628521%40sss.pgh.pa.us We might want to retry again to see if later versions have changed as it was almost 10 years ago when we tried this. From marco at boeringa.demon.nl Wed Dec 3 12:54:22 2025 From: marco at boeringa.demon.nl (Marco Boeringa) Date: Wed, 3 Dec 2025 21:54:22 +0100 Subject: Problem with ST_NRings In-Reply-To: <000d01dc6419$8152f5d0$83f8e170$@pcorp.us> References: <208b2838-64cc-40d4-8adf-9ef5babb7b67@boeringa.demon.nl> <46a6eb56-0bdd-44f5-a198-2a6c6d11dab5@boeringa.demon.nl> <000c01dc6406$4a94f650$dfbee2f0$@pcorp.us> <000d01dc6419$8152f5d0$83f8e170$@pcorp.us> Message-ID: <9d6939bc-cd47-4b81-ba21-a7624ef418ab@boeringa.demon.nl> Op 3-12-2025 om 06:56 schreef Regina Obe: >>> It would be better if you used the fully qualified name. >>> Using search_path in a function crushes query performance. >>> >>> CREATE FUNCTION my_func(public.geometry) >>> RETURNS int >>> AS $$ SELECT public.ST_NRings($1); $$ LANGUAGE sql; >> Hi Regina, >> >> Thanks for that important warning about the performance aspect. However, >> do you possibly have any real world figures of how much of a difference this >> makes? Just doing an internet search on 'search_path' and 'performance' >> doesn't turn up much of relevant results for something that might be critical. I >> can see how a custom search path loaded with objects might turn a 'search' >> into a heavy operation, but I would expect PostgreSQL to at least cache some >> reference to the main functions and objects of system 'public', 'pg_catalog' >> and 'pg_temp' schema's, but maybe I am just naive here? >> >> Although I could change the code, having to add 'public' before each PostGIS >> function or class, would make my Python code assembling queries a lot less >> readable. Or is the performance issue you express concerns about mainly >> related to function definitions like in CREATE FUNCTION, which would make >> adjustment much more straightforward, as it would only require modifying the >> function definitions themselves, not all uses in SQL? >> >> Marco > Only pertains to putting it in functions variable settings. > As I understand it changes the function then runs in isolation. > > I did this earlier on putting it in postgis search path function setting, cause that was faster than schema qualifying > And it made queries so unbearably slow that I had to roll back that change. > I thought maybe it would only affect index usage, but it even slowed down functions such as ST_Distance. > > Tom Lane described it here: > > https://www.postgresql.org/message-id/9914.1457628521%40sss.pgh.pa.us > > We might want to retry again to see if later versions have changed as it was almost 10 years ago when we tried this. Hi Regina, Thanks for that insight and also the interesting link you included. I have resolved my issues per your recommendation, and now included the 'public' schema reference in all necessary places in the few custom functions I have. Seems to work fine now. Marco From jgr at di.uminho.pt Fri Dec 12 17:19:29 2025 From: jgr at di.uminho.pt (Jorge Gustavo Rocha) Date: Sat, 13 Dec 2025 01:19:29 +0000 Subject: ogr2ogr with missing geometries crashes postgresql with segmentation fault Message-ID: Hi, TL;DR A GIST index on a EMPTY POLYGON (encoded by GDAL) crashes postgresql with segmentation fault. drop table if exists fault; create table fault (fid integer, geom geometry(Polygon,5015)); INSERT INTO fault (fid, geom) VALUES (1, '0103000020971300000100000000000000'::GEOMETRY); CREATE INDEX fault_geom_index ON fault USING GIST (geom); Postgresql log: 2025-12-13 00:53:11.879 UTC [12360] LOG:? client backend (PID 18218) was terminated by signal 11: Segmentation fault 2025-12-13 00:53:11.879 UTC [12360] DETAIL:? Failed process was running: CREATE INDEX fault_geom_index ON fault USING GIST (geom); 2025-12-13 00:53:11.879 UTC [12360] LOG:? terminating any other active server processes 2025-12-13 00:53:11.881 UTC [18263] postgres at idea FATAL:? the database system is in recovery mode 2025-12-13 00:53:11.883 UTC [12360] LOG:? all server processes terminated; reinitializing 2025-12-13 00:53:11.899 UTC [18267] LOG:? database system was interrupted; last known up at 2025-12-13 00:52:07 UTC 2025-12-13 00:53:11.909 UTC [18267] LOG:? database system was not properly shut down; automatic recovery in progress That geometry was encoded by ogr2ogr: idea=# select ST_AsEWKT('0103000020971300000100000000000000'::GEOMETRY); ? ? ? ? st_asewkt ------------------------- ?SRID=5015;POLYGON EMPTY The same geometry encoded by Postgis does not crashes postgresql. drop table if exists fault; create table fault (fid integer, geom geometry(Polygon,5015)); INSERT INTO fault (fid, geom) VALUES (2, ST_GeomFromEWKT('SRID=5015;POLYGON EMPTY')); CREATE INDEX fault_geom_index ON fault USING GIST (geom); No errors. Different encodings. Both valid using st_isvalid(): ogr2ogr encode of? 'SRID=5015;POLYGON EMPTY': 0103000020971300000100000000000000 postgis encode of? ?'SRID=5015;POLYGON EMPTY': 01030000209713000000000000 idea=# select st_isvalid('0103000020971300000100000000000000'::GEOMETRY), st_isvalid('01030000209713000000000000'::GEOMETRY); ?st_isvalid | st_isvalid ------------+------------ ?t? ? ? ? ? | t /TL;DR Long story I have a postgresql database that is crashing a few times, with Segmentation fault. Users are uploading data (they called it data!) with ogr2ogr. The files have issues, like missing geometries and so on. I'm attaching one of such files. Using QGIS If I run the validity check on QGIS the file is ok, but there are missing geometries. QGIS doesn't complain about it. Uploading the file to postgis within QGIS fails, but fails with a nice error: 2025-12-12 22:51:18.871 UTC [13255] idea at idea ERROR:? Polygon must have at least four points in each ring 2025-12-12 22:51:18.871 UTC [13255] idea at idea CONTEXT:? SQL function "st_geomfromwkb" statement 1 2025-12-12 22:51:18.871 UTC [13255] idea at idea STATEMENT:? INSERT INTO "upload"."geojson ? 8a2bdfa0859a7663b1e3f3b947f933ed"("geom","fid","tema","igt","freguesia","concelho","shape_length") VALUES (st_geomfromwkb($1::bytea,5015),$2,'Limite de Concelho','Plano Regional de Ordenamento do Territ?rio',NULL,$3,$4) That is what I was expecting. Errors reported, but no segmentation fault. Using ogr2ogr Using ogr2ogr to upload the same files crashes the postgresql server. ogr2ogr "PG:host='x.x.x.x' port='xxxx' user='xxx' password='xxx' dbname='idea' active_schema=upload" 8a2bdfa0859a7663b1e3f3b947f933ed.geojson Postgresql log: 2025-12-12 23:06:08.215 UTC [12360] LOG:? client backend (PID 13893) was terminated by signal 11: Segmentation fault 2025-12-12 23:06:08.215 UTC [12360] DETAIL:? Failed process was running: COPY "8a2bdfa0859a7663b1e3f3b947f933ed" ("wkb_geometry", "tema", "igt", "freguesia", "concelho", "shape_length") FROM STDIN; 2025-12-12 23:06:08.215 UTC [12360] LOG:? terminating any other active server processes 2025-12-12 23:06:08.219 UTC [12360] LOG:? all server processes terminated; reinitializing 2025-12-12 23:06:08.235 UTC [13898] LOG:? database system was interrupted; last known up at 2025-12-12 23:04:25 UTC 2025-12-12 23:06:08.247 UTC [13898] LOG:? database system was not properly shut down; automatic recovery in progress Differences QGIS upload is using INSERT and?st_geomfromwkb. ogr2ogr is using COPY, but encodes the geometry beforehand. I've tried ogr2ogr with INSERT, but the crash happens again. PG_USE_COPY=NO ogr2ogr -skipfailures "PG:host='x.x.x.x' port='xxxx' user='xxx' password='xxx' dbname='idea' active_schema=upload" /home/qgis/public_html/uploads/8a2bdfa0859a7663b1e3f3b947f933ed.geojson 2025-12-12 23:59:01.494 UTC [12360] LOG:? client backend (PID 16042) was terminated by signal 11: Segmentation fault 2025-12-12 23:59:01.494 UTC [12360] DETAIL:? Failed process was running: INSERT INTO "8a2bdfa0859a7663b1e3f3b947f933ed" ("wkb_geometry" , "tema", "igt", "freguesia", "concelho", "shape_length") VALUES ('0103000020971300000100000000000000'::GEOMETRY, 'Limite de Concelho', 'Plano Regional de Ordenamento do Territ??rio', NULL, NULL, 0.106232057407228) RETURNING "ogc_fid" 2025-12-12 23:59:01.494 UTC [12360] LOG:? terminating any other active server processes 2025-12-12 23:59:01.498 UTC [12360] LOG:? all server processes terminated; reinitializing 2025-12-12 23:59:01.514 UTC [16047] LOG:? database system was interrupted; last known up at 2025-12-12 23:58:01 UTC 2025-12-12 23:59:01.526 UTC [16047] LOG:? database system was not properly shut down; automatic recovery in progress The ogr2ogr encoded geometry that caused the segmentation fault is valid. select st_isvalid('0103000020971300000100000000000000'::GEOMETRY); Isolating the problem The following query raised the segmentation fault: INSERT INTO upload."8a2bdfa0859a7663b1e3f3b947f933ed" ("wkb_geometry" , "tema", "igt", "freguesia", "concelho", "shape_length") VALUES ('0103000020971300000100000000000000'::GEOMETRY, 'Limite de Concelho', 'Plano Regional de Ordenamento', NULL, NULL, 0.106232057407228); That geometry is: idea=# select ST_AsEWKT('0103000020971300000100000000000000'::GEOMETRY); ? ? ? ? st_asewkt ------------------------- ?SRID=5015;POLYGON EMPTY This alternative works: INSERT INTO upload."8a2bdfa0859a7663b1e3f3b947f933ed" ("wkb_geometry" , "tema", "igt", "freguesia", "concelho", "shape_length") VALUES (ST_GeomFromEWKT('SRID=5015;POLYGON EMPTY'), 'Limite de Concelho', 'Plano Regional de Ordenamento', NULL, NULL, 0.106232057407228); After further investigation, I found out that the problem is the GIST index. If the index exists, when we do the INSERTS with ogr2ogr encoded?empty polygons, the server crashes. If there is no index, there is no problem. Further comments are welcome. I don't know exactly if it is a Postgis or a GDAL problem, but this should not crash Postgresql. Environment This Segmentation fault happens with Postgresql 17 or 18 + Postgis 3.6.1 + Ubuntu 24.04.3: POSTGIS="3.6.1 f533623" [EXTENSION] PGSQL="180" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" ( compiled against PROJ 9.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER qgis at s0618idea02:~$ dpkg -l | grep gdal ii? gdal-bin? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.8.4+dfsg-3ubuntu3 ? ? ? ? ? ? ? ? ?amd64? ? ? ? Geospatial Data Abstraction Library - Utility programs ii? gdal-data? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?3.8.4+dfsg-3ubuntu3 ? ? ? ? ? ? ? ? ?all? ? ? ? ? Geospatial Data Abstraction Library - Data files ii? gdal-plugins:amd64? ? ? ? ? ? ? ? ? ? ? 3.8.4+dfsg-3ubuntu3 ? ? ? ? ? ? ? ? ?amd64? ? ? ? Geospatial Data Abstraction Library - Plugins ii? libgdal34t64:amd64? ? ? ? ? ? ? ? ? ? ? 3.8.4+dfsg-3ubuntu3 ? ? ? ? ? ? ? ? ?amd64? ? ? ? Geospatial Data Abstraction Library ii? python3-gdal? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.8.4+dfsg-3ubuntu3 ? ? ? ? ? ? ? ? ?amd64? ? ? ? Python 3 bindings to the Geospatial Data Abstraction Library Regards, Jorge -------------- next part -------------- A non-text attachment was scrubbed... Name: 8a2bdfa0859a7663b1e3f3b947f933ed.geojson Type: application/geo+json Size: 106583 bytes Desc: not available URL: From akrherz at gmail.com Sat Dec 13 05:38:31 2025 From: akrherz at gmail.com (Daryl Herzmann) Date: Sat, 13 Dec 2025 07:38:31 -0600 Subject: ogr2ogr with missing geometries crashes postgresql with segmentation fault In-Reply-To: References: Message-ID: On Fri, Dec 12, 2025 at 7:20?PM Jorge Gustavo Rocha wrote: > > Hi, > > TL;DR > > A GIST index on a EMPTY POLYGON (encoded by GDAL) crashes postgresql > with segmentation fault. > > drop table if exists fault; > create table fault (fid integer, geom geometry(Polygon,5015)); > INSERT INTO fault (fid, geom) VALUES (1, > '0103000020971300000100000000000000'::GEOMETRY); > CREATE INDEX fault_geom_index ON fault USING GIST (geom); FWIW, this reproducer crashed my Postgresql 18 + postgis 3.6.0 (both from PGDG) + Alma Linux 9 as well. ... INSERT 0 1 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. The connection to the server was lost. Attempting reset: Failed. !?> !?> quit $ psql psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: the database system is in recovery mode daryl From pramsey at cleverelephant.ca Sat Dec 13 18:28:09 2025 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Sat, 13 Dec 2025 18:28:09 -0800 Subject: ogr2ogr with missing geometries crashes postgresql with segmentation fault In-Reply-To: References: Message-ID: <1496D634-9F2D-4798-856C-B1AC7695B86B@cleverelephant.ca> First, thank you for a perfect minimal reproducer right up front. Very helpful and I have confirmed a crash here too. I haven?t put it into the debugger yet. Your empty polygon is pretty cool (as polygons tend to be) since it is not a classic ?polygon with no rings? empty polygon, it is a ?polygon with one ring that has no points? empty polygon. 01 // LITTLE ENDIAN. 03000020 // POLYGON, WITH SRID 97130000 // SRID 5015 01000000 // ONE RING 00000000 // ZERO POINTS Why that causes a crash in the index code (or perhaps the bounding box extraction code) is yet to be determined. Anyways, very exciting to have a crasher, quite a rare defect these days. ATB, P. > On Dec 12, 2025, at 5:19?PM, Jorge Gustavo Rocha wrote: > > TL;DR > > A GIST index on a EMPTY POLYGON (encoded by GDAL) crashes postgresql with segmentation fault. > > drop table if exists fault; > create table fault (fid integer, geom geometry(Polygon,5015)); > INSERT INTO fault (fid, geom) VALUES (1, '0103000020971300000100000000000000'::GEOMETRY); > CREATE INDEX fault_geom_index ON fault USING GIST (geom); -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Mon Dec 15 09:15:22 2025 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Mon, 15 Dec 2025 09:15:22 -0800 Subject: ogr2ogr with missing geometries crashes postgresql with segmentation fault In-Reply-To: <1496D634-9F2D-4798-856C-B1AC7695B86B@cleverelephant.ca> References: <1496D634-9F2D-4798-856C-B1AC7695B86B@cleverelephant.ca> Message-ID: I have started a ticket, and have a fix in hand. https://trac.osgeo.org/postgis/ticket/6028 On Sat, Dec 13, 2025 at 6:28?PM Paul Ramsey wrote: > First, thank you for a perfect minimal reproducer right up front. Very > helpful and I have confirmed a crash here too. I haven?t put it into the > debugger yet. Your empty polygon is pretty cool (as polygons tend to be) > since it is not a classic ?polygon with no rings? empty polygon, it is a > ?polygon with one ring that has no points? empty polygon. > > 01 // LITTLE ENDIAN. > 03000020 // POLYGON, WITH SRID > 97130000 // SRID 5015 > 01000000 // ONE RING > 00000000 // ZERO POINTS > > Why that causes a crash in the index code (or perhaps the bounding box > extraction code) is yet to be determined. > Anyways, very exciting to have a crasher, quite a rare defect these days. > ATB, > P. > > > On Dec 12, 2025, at 5:19?PM, Jorge Gustavo Rocha wrote: > > TL;DR > > A GIST index on a EMPTY POLYGON (encoded by GDAL) crashes postgresql with > segmentation fault. > > drop table if exists fault; > create table fault (fid integer, geom geometry(Polygon,5015)); > INSERT INTO fault (fid, geom) VALUES (1, > '0103000020971300000100000000000000'::GEOMETRY); > CREATE INDEX fault_geom_index ON fault USING GIST (geom); > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Mon Dec 15 16:35:33 2025 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Mon, 15 Dec 2025 16:35:33 -0800 Subject: ogr2ogr with missing geometries crashes postgresql with segmentation fault In-Reply-To: References: <1496D634-9F2D-4798-856C-B1AC7695B86B@cleverelephant.ca> Message-ID: Should be fixed in all stable branches and going forward. On Mon, Dec 15, 2025 at 9:15?AM Paul Ramsey wrote: > I have started a ticket, and have a fix in hand. > > https://trac.osgeo.org/postgis/ticket/6028 > > On Sat, Dec 13, 2025 at 6:28?PM Paul Ramsey > wrote: > >> First, thank you for a perfect minimal reproducer right up front. Very >> helpful and I have confirmed a crash here too. I haven?t put it into the >> debugger yet. Your empty polygon is pretty cool (as polygons tend to be) >> since it is not a classic ?polygon with no rings? empty polygon, it is a >> ?polygon with one ring that has no points? empty polygon. >> >> 01 // LITTLE ENDIAN. >> 03000020 // POLYGON, WITH SRID >> 97130000 // SRID 5015 >> 01000000 // ONE RING >> 00000000 // ZERO POINTS >> >> Why that causes a crash in the index code (or perhaps the bounding box >> extraction code) is yet to be determined. >> Anyways, very exciting to have a crasher, quite a rare defect these days. >> ATB, >> P. >> >> >> On Dec 12, 2025, at 5:19?PM, Jorge Gustavo Rocha >> wrote: >> >> TL;DR >> >> A GIST index on a EMPTY POLYGON (encoded by GDAL) crashes postgresql with >> segmentation fault. >> >> drop table if exists fault; >> create table fault (fid integer, geom geometry(Polygon,5015)); >> INSERT INTO fault (fid, geom) VALUES (1, >> '0103000020971300000100000000000000'::GEOMETRY); >> CREATE INDEX fault_geom_index ON fault USING GIST (geom); >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgr at di.uminho.pt Mon Dec 15 16:55:02 2025 From: jgr at di.uminho.pt (Jorge Gustavo Rocha) Date: Tue, 16 Dec 2025 00:55:02 +0000 Subject: ogr2ogr with missing geometries crashes postgresql with segmentation fault In-Reply-To: References: <1496D634-9F2D-4798-856C-B1AC7695B86B@cleverelephant.ca> Message-ID: Amazing work, Paul! Thank you, Jorge ?s 00:35 de 16/12/25, Paul Ramsey escreveu: > Should be fixed in all stable branches and going forward. > > On Mon, Dec 15, 2025 at 9:15?AM Paul Ramsey > wrote: > > I have started a ticket, and have a fix in hand. > > https://trac.osgeo.org/postgis/ticket/6028 > > On Sat, Dec 13, 2025 at 6:28?PM Paul Ramsey > wrote: > > First, thank you for a perfect minimal reproducer right up > front. Very helpful and I have confirmed a crash here too. I > haven?t put it into the debugger yet. Your empty polygon is > pretty cool (as polygons tend to be) since it is not a classic > ?polygon with no rings? empty polygon, it is a ?polygon with > one ring that has no points? empty polygon. > > ? 01 // LITTLE ENDIAN. > ? 03000020 // POLYGON, WITH SRID > ? 97130000 // SRID 5015 > ? 01000000 // ONE RING > ? 00000000 // ZERO POINTS > > Why that causes a crash in the index code (or perhaps the > bounding box extraction code) is yet to be determined. > Anyways, very exciting to have a crasher, quite a rare defect > these days. > ATB, > P. > > >> On Dec 12, 2025, at 5:19?PM, Jorge Gustavo Rocha >> wrote: >> >> TL;DR >> >> A GIST index on a EMPTY POLYGON (encoded by GDAL) crashes >> postgresql with segmentation fault. >> >> drop table if exists fault; >> create table fault (fid integer, geom geometry(Polygon,5015)); >> INSERT INTO fault (fid, geom) VALUES (1, >> '0103000020971300000100000000000000'::GEOMETRY); >> CREATE INDEX fault_geom_index ON fault USING GIST (geom); > -------------- next part -------------- An HTML attachment was scrubbed... URL: