Provide alternate malloc/free at run time

[pramsey]

We are currently grappling with a pretty big issue in the PostGIS/GEOS integration, namely that PgSQL allocates it's memory inside pools (palloc/pfree), while GEOS allocates in general memory (malloc/free). This (a) imposes a requirement of memory management perfection on GEOS, otherwise the long-running postgres processes will leak and (b) can lead to insoluble problems in certain implementation patterns.

We have recently found one such problem pattern. When using preparedgeometry in postgis, we create a GEOS geometry and associated prepared geometry, these are duly malloc'ed, but we store references to them in a palloc'ed struct in a memory pool which lasts for the life of a postgres query. All is good (well, there are memory leaks in the prepared stuff still, but those are theoretically fixable) until the end of the query, when postgres cleans up the query memory pool. All of a sudden the struct with the references to the geometry and prepared geometry are gone -- but the objects have not been freed.

Basically, the prepared geometry system will leak one geometry and one prepared geometry for every SQL statement run, and there's SFA we can do about it.

My immodest proposal is to use geosInit as a location where users can provide their own allocator/deallocators. Right now, geosInit lets us set custom error handlers, so this extends the idea further.

In GEOS we would override new/delete in GEOS to our own functions that would check and see if the custom alloc/dealloc functions were set. If not, they would fall back to malloc/free, otherwise use what was provided. For postgis, we would provide palloc/pfree in our geosInit calls.

In this way, we could hook GEOS into the PgSQL pool system at runtime, while still have it operate in the normal way when used with other applications. And other applications with their own memory systems could also more tightly integrate GEOS.

[pramsey]

Prototype implementation

[pramsey]

Using a PostgreSQL trick from Mark Cave-Ayland, this is no longer a critical issue for PostGIS, so this idea is being shelved until someone else has an existential need for it.

[(none)]

Milestone 3.1.0 deleted