Re: Memory management question

On Tue, 3 Sep 2002, Karel Zak wrote:

> On Tue, Sep 03, 2002 at 12:28:37PM +0100, Nigel J. Andrews wrote:
> >
> >
> > It's probably a pretty basic question explained in some document I haven't seen
> > but...if I do something like a CreateTupleDescCopy() how do I know my memory
> > context owns everything allocated without following the code all the way
> > through until it returns to me?
>
> If some code doesn't call MemoryContextSwitchTo() all is allocated in
> current memory context. You can check if CurrentMemoryContext is same
> before and after call that is important for you - but this check say
> nothing, bacuse some code can switch to other context and after usage
> switch back to your context. IMHO is not common way how check it.
> (Ok, maybe check all contexts size before/after call...)
>
> Suggestion: add to memory managment counter that handle number
> of MemoryContextSwitchTo() calls. IMHO it can be compile
> only if MEMORY_CONTEXT_CHECKING is define.

I quite like that idea. Only thing is it doesn't full address the issue of
identifying if my context owns memory allocated by other functions I've
used. For example:

A called procedure could be doing (psuedo code obviously):

SwitchContext()
mem=palloc(anumber)
/* use mem */
pfree(mem)
SwitchContectBack()
retmem=palloc(anothersize)

There, net effect is that I do own retmem but the test on context switch
counters would indicate that I may not.

I think the problem is that I don't fully understand why [and when] is context
switch is or should be done.

> But I think there is not to much places which switching between
> contexts and all are good commented (I hope, I wish :-)

As someone pointed out my example wasn't very complex so checking the source
wasn't onerous. Checking something like heap_modifytuple() is more time
consuming.

I was hoping there was some sort of 'rule of thumb'. In general I can't see how
it could be sensibly known without such a rule and without tracing through the
source.

--
Nigel J. Andrews