On Wed, 2008-10-01 at 11:33 -0700, Paul Ramsey wrote: > Mark, there's two issues at play here: > > (1) - GEOS leaks, independently of the pgsql use of it, and yes, that > should be fixed > (2) - when you place a reference to a GEOS malloc'ed object in a > palloc'ed struct in pgsql, if the memorycontext where the struct > resides is cleaned up, you leak the GEOS object > > It's (2) which seems to require a callback and hooks to do memory work > inside the pgsql pools. BTW, the XML support in PgSQL also uses > callbacks to do the memory allocation inside the pgsql pools, I have > found. However, as a core module, they get to create their own memory > context and have a piece of code right in core that cleans up their > context at the end of a transaction block. > > If, alternately, the pgsql function manager provided a way to know > when fcinfo->flinfo->fn_mcxt was going to be freed, we could keep all > our GEOS objects in malloc'ed space and clean them up before the > context was freed.
Ah but we do this in PostGIS already - this is exactly how I implemented caching for PROJ.4 objects :) The way it works is to attach our own set of methods to a new child memory context of the function context. Then when this is context is destroyed at the end of the query/abort, we can go through the list and free everything as required. Now the trick would be to do this hierarchically: say for example you have something like this in GEOS: Geometry | CoordinateSequence | Coordinate Thus each layer would store the list of malloc()d pointers for everything in the immediate layer below it. This would then mean that we would only need to track the topmost pointer within PostGIS since deletion of this object would automatically cause a cascade deletion of everything else. ATB, Mark. _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel