Memory management in postgres (with liblwgeom functions in particular) - Mailing list pgsql-general

From Igor Stassiy
Subject Memory management in postgres (with liblwgeom functions in particular)
Date
Msg-id CAKVOjewa5NfaoVwfjkGqiNuPJdYQATGtKaNdz2ycrjPnU8KfKg@mail.gmail.com
Whole thread Raw
Responses Re: [postgis-users] Memory management in postgres (with liblwgeom functions in particular)  (Paul Ramsey <pramsey@cleverelephant.ca>)
List pgsql-general
Hello,

I am developing a C++ extension (most of the code is C++) for postgres that links dynamically with liblwgeom, without linking to postgis. I call liblwgeom functions that serialize/deserialize LWGEOM* (and similar structures) that don't need a backend like GEOS.

I wonder how is the memory freed when we call lwerror, as the transaction will be terminated (elog/ereport create a long jump), so if I call liblwgeoms functions from within C++, the stack will not be unwind and even if I use smart pointers it wouldn't make a difference (right?).

On the contrary, when Postgis module loads itself, in _PG_init it overrides memory allocation functions of liblwgeom with pg_alloc and pg_free. Which in turn call palloc and pfree. And in this case when we call lwerror, the memory that we allocated is freed automatically (right?).

I guess (just a guess) it has something to do with the memory context and when a memory context is "closed" the entire memory allocated within would be freed. But lwalloc by default is malloc, so does Postgres do something extremely clever like overriding malloc with its palloc?

Thank you,
Igor

pgsql-general by date:

Previous
From: Deven Phillips
Date:
Subject: Re: Foreign Data Wrapper for remote view?
Next
From: John R Pierce
Date:
Subject: Re: Link Office Word form document with data from PostgreSQL