On Tue, Dec 19, 2017 at 7:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Paul Ramsey <pramsey@cleverelephant.ca> writes:
>> Our use of MemoryContextCreate is solely in order to get use
>> MemoryContextDelete as a callback so that, at the end of a statement,
>> we can clean up externally allocated memory that we're holding in a
>> cache. If we had some other callback to use for "the statement is
>> complete, you can clean up now", we could avoid all this mucking
>> around with raw MemoryContexts entirely. The MemoryContext trick/hack
>> is very old, perhaps a callback or hook has been added since then that
>> we could make use of?
>
> However, if the need is to free some external resources when a memory
> context is destroyed, seems like what you ought to be using is a memory
> context reset callback. Look at MemoryContextRegisterResetCallback and
> its callers (there are just a couple at the moment, though I'm fooling
> with a patch that will add more).
During a query we'll look up a coordinate transformation object, which
is an expensive lookup, and want to keep it around for the duration of
the query. For extra fun, it's externally allocated, not palloc'ed.
When the query ends, we want to clean up the objects associated with
that query.
Right now the trick is to create our custom memorycontext that has its
delete method dedicated to cleaning out entries in our cache.
If I'm reading right, using MemoryContextRegisterResetCallback on a
AllocSetContext created under our PortalContext should do the trick,
with less direct mucking about into the internals of contexts.
P
