[geos-devel] An Immodest Proposal

[Mark Cave-Ayland]

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.