On Thu, Mar 20, 2008 at 12:27 AM, Dan Searle <dan@adelix.com> wrote:
>
> I had to fiddle about with switching memory contexts rather a lot to
> make it work this far, but I'm only guessing as to when it's appropriate
> to call MemoryContextSwitchTo(), and to which context to switch to
Here is what I know. Not sure whether it would answer your question though.
A memory context is a memory enclosure with a life associated to it. Whenever
the context is freed, all objects allocated in that context are also
automatically
freed. If there are any references to these objects, they will turn
into dangling
pointers, causing segfaults and/or memory corruption. So you need to be
careful while choosing a memory context to allocate memory from. You
don't want to allocate something in a long-lived context if you don't need
it for that much time because failure to explicitely free the allocation will
result in memory consumption when its not required or even a memory leak.
OTOH you don't want to allocate something in a very short-live context,
if you may require that object outside the scope of that context.
Certain memory contexts are well known. For example, a TopMemoryContext
has life of the session. Any object allocated in this context would remain
valid for the entire session. Of course, failure to free them would result
in memory leaks.
TopTransactionContext, as the name suggests, is valid in the current
top transaction. As soon as the transaction commits/aborts, the context
is freed.
CurrentTransactionContext, which may be same as TopTransactionContext
remains valid for the current transaction or subtransaction.
Apart from that, there are contexts attached to different objects during
execution and their lifespan is usually attached to the lifespan of the object
itself. You may need to choose one of them if you know that what you
are allocating can not or should not outlive that object.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com