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

Reply via email to