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 <[EMAIL PROTECTED]> wrote: > On Thu, Mar 20, 2008 at 12:27 AM, Dan Searle <[EMAIL PROTECTED]> 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- EnterpriseDB http://www.enterprisedb.com
