AW: [PostGIS] ST_3DIntersection query hangs (PostGIS 3.4, PostgreSQL 15.12, SFCGAL 1.5.0)

Fri Sep 5 05:31:29 PDT 2025

Hi all,
thank you, Regina, for the detailed explanations and support — and apologies for the delayed reply.

We were able to narrow the issue down to a single geometry. Both ST_IsValid and ST_IsValidDetail report this geometry as valid.
- ST_ForceLHR did not resolve the issue
- Updating to SFCGAL 1.5.2 also did not fix it

In our query example (see initial post), both EDGE_A and EDGE_B correspond exactly to this geometry. We now prevent such a geometry from being passed into ST_3DIntersection. Still, we think it would be important for the function either to handle such geometries gracefully or to return a clear error instead of hanging (requiring termination at the OS level).

We are happy to provide the geometry for reproduction, see below.
Is there any further information we could provide or tests we could run to help analyze this issue?

Roland

LINESTRING ZM (
2709311.8710001106 1270238.2919939812 393.24800000000687 0,
2709314.261 1270230.638 393.697 8.031022620749106,
2709318.253 1270219.87 394.678 19.55700409735401,
2709308.135 1270215.322 394.352 30.654954539067475,
2709283.723 1270205.854 393.158 56.86591415476034,
2709258.847 1270196.294 392.117 83.53598458978588,
2709221.63 1270181.499 391.052 123.60007498269391,
2709220.73 1270184.774 391.052 126.9964885321932,
2709233.11 1270192.807 390.657 141.7596018216759,
2709238.377 1270195.906 390.666 147.87067136795687,
2709249.469 1270201.173 390.777 160.15016948489506,
2709268.803 1270210.964 390.958 181.82273273873287,
2709281.692 1270218.214 391.046 196.6111256534189,
2709300.593 1270228.253 391.421 218.01603039520197,
2709305.674 1270231.103 392.048 223.87539810866957,
2709308.524 1270233.272 392.591 227.4978158098074,
2709309.826 1270234.945 392.893 229.6391558105999,
2709311.8710001106 1270238.2919939812 393.24800000000687 233.57748276032353,
2709311.4680001102 1270241.6949939842 393.1579999999958 237.0054439649563,
2709308.769000113 1270252.1719939825 393.0040000000008 247.82560320361586,
2709304.960000112 1270263.6009939841 392.81699999999546 259.87406746440917,
2709303.1340001114 1270270.9019939767 392.7719999999972 267.4000824719586,
2709302.2610001117 1270273.3629939815 392.7979999999952 270.0114664006391,
2709301.7850001114 1270277.886993982 392.8709999999992 274.561024731316
)

-----Ursprüngliche Nachricht-----
Von: Regina Obe <lr at pcorp.us> 
Gesendet: Donnerstag, 28. August 2025 17:44
An: Maron Roland swisstopo <roland.maron at swisstopo.ch>; postgis-users at lists.osgeo.org
Betreff: RE: [PostGIS] ST_3DIntersection query hangs (PostGIS 3.4, PostgreSQL 15.12, SFCGAL 1.5.0)

Roland,

Just a clarification here.  ST_3DIntersection, just got a renaming to CG_3DIntersection to make it clear it's an SFCGAL function as discussed
here -  https://trac.osgeo.org/postgis/ticket/5405   so it will still be
available in 3.5 and beyond.
This is to prevent confusion of what is SFCGAL and what is GEOS -- as we had major issues with ST_3DIntersects (in that the SFCGAL version of it was not accessible because PostGIS GEOS ST_3DIntersects took it's place when we removed the sfcgal backend switch and lots of people complained about ST_3DIntersects being broken cause for example it didn't handle solids anymore.).

So this is just to future proof things

That said, I know a number of issues have been addressed since SFCGAL 1.5.0, have you tried upgrading to SFCGAL 1.5.2

https://gitlab.com/sfcgal/SFCGAL/-/releases/v1.5.2

I think the culprit of a lot of these issues is the LHR / RHR orientation which caused a lot of functions such as ST_3DIntersection to fail or hang.

So if you can't upgrade to 1.5.2 or higher, try using https://postgis.net/docs/manual-3.4/ST_ForceLHR.html

ST_3DIntersection(
            (SELECT ST_ForceLHR(geom) FROM geo_edge WHERE pk_id = a.EDGE_A),
           (SELECT ST_ForceLHR(geom) FROM geo_edge WHERE pk_id = a.EDGE_B)
        )

To see if it fixes your issue.

IF that still doesn't please try to isolate some geometries that trigger the issue.

> Hi List
> 
> We are encountering a problem when using ST_3DIntersections.
> 
> Context:
> A quality-check identifies candidate geometries (error_multipoints). 
> We
then
> load the corresponding geo_edge.geom values and compute intersections. 
> All input geometries are valid.
> 
> Query:
> WITH id1 AS (
>     SELECT
>         (string_to_array(involved_objects, ';'))[2]::int AS EDGE_A,
>         (string_to_array(involved_objects, ';'))[4]::int AS EDGE_B
>     FROM error_multipoints
>     WHERE user_name = 'test_xxx'
> )
> SELECT
>     a.EDGE_A,
>     a.EDGE_B,
>     ST_AsText(
>         ST_3DIntersection(
>             (SELECT geom FROM geo_edge WHERE pk_id = a.EDGE_A),
>             (SELECT geom FROM geo_edge WHERE pk_id = a.EDGE_B)
>         )
>     ) AS INTERSECTIONS_3d
> FROM id1 AS a;
> 
> Problem/observation:
> - CPU goes to 100% immediately, query never finishes.
> - Client never receives a response.
> - Process cannot be terminated inside PostgreSQL, only at OS level.
> - With limit of 4000 records everything works within seconds.
> - With limit of 5000 records the issue always appears → memory leak?
> 
> Setup:
> - PostgreSQL 15.12
> - Postgis 3.4 (USE_GEOS=1 USE_PROJ=1 USE_STATS=1)
> - SFCGAL 1.5.0
> 
> Remarks:
> - We are aware ST_3DIntersection is deprecated (PostGIS ≥ 3.5), but we
still
> rely on it in some workflows.
> - We are aware that the query could be written more efficiently using
JOIN,
> but for the sake of reproducibility, we are sticking with this example
for the
> time being.
> 
> Question:
> Has anyone experienced similar hangs with ST_3DIntersection at scale?
> Any ideas if this is related to SFCGAL memory handling, or known 
> limitations/workarounds?
> What exactly is happening that prevents me from terminating the 
> process inside PostgreSQL?
> 
> Thanks for your input and ideas!
> Roland