Re: MemoryContextSwitchTo() confusion

src/backend/utils/mmgr/README contains more information about the same too.

Regards,
Nikhils

On Thu, Mar 20, 2008 at 2:41 PM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
wrote:

> On Thu, Mar 20, 2008 at 12:27 AM, Dan Searle <dan(at)adelix(dot)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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
EnterpriseDB http://www.enterprisedb.com