topology: postgres runs out of memory on loading geometry using toTopoGeom

[rulus]

I first noticed this issue in the 2.2 branch (2.2.2dev) but could reproduce using the latest svn-trunk revision.

When loading a new geometry into an existing topology, the postgres process runs out of memory and is eventually killed by my OS (Debian).

I'm using versions

PostgreSQL 9.4.5 on x86_64-unknown-linux-gnu, 
compiled by gcc (Debian 5.2.1-23) 5.2.1 20151028, 64-bit

POSTGIS="2.3.0dev r14623" GEOS="3.5.0-CAPI-1.9.0 r4084" 
PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 2.0.1, 
released 2015/09/15" LIBXML="2.9.3" LIBJSON="0.11.99" TOPOLOGY 
RASTER

The statement I'm using to import the geometry:

insert into data.gwl (id, naam, topogeom) 
select 101, localid, topology.toTopoGeom(geom, 'gwl', 1, 0.01) 
from src."RBD_VL" where localid = 'Maas_VL';

Which is killed after a few minutes:

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.

Loading the same geometry in an empty topology is succesful.

Since there is no crash as such, getting a backtrace as described in ​https://trac.osgeo.org/postgis/wiki/DevWikiGettingABackTrace is not possible.

Sharing the full db is difficult, however I'm available to debug the issue further. I'm not experienced in debugging memory issues, maybe someone can give a hint on how to proceed?

[strk]

Disabling the OOM killer should make debugging easier. Splitting the inputs to avoid a single new geometry's bounding box to intersect lots of existing components should reduce memory usage.

[rulus]

Adding a small nuance here: this might actually not be a bug :)

By disabling the OOM killer and raising the memory of the VM (from 2GB to 4GB) I managed to import the failing geometry without problems. It seems that it's just using more memory than I thought it would..

Thanks for the suggestions!

[strk]

Thank you for confirming, will close as "wontfix" for now, but shall you feel operations are really using too much memory feel free to file a new enhancement ticket to reduce memory usage during topology population (after checking that no other similar tickets already exist)