Re: Misc. consequences of backend memory management changes - Mailing list pgsql-hackers

Karel Zak <zakkr@zf.jcu.cz> writes:
>  Well, I a little surprise that you remove all aset definiton from
> header files to aset.c. If anyone will write new context type, he
> can't uses some already exist definition.

>  IMHO not will bad if all context types (now exists aset type only)
> will more transparently and will own header files and at first sight will
> visible what is common memory routines and what specific.

I left AllocSetContext in memnodes.h temporarily, but I think in the
long run it should only be defined inside aset.c.  Anyone else have
an opinion on that?

> About context tree --- what will happen if in PG will exist some context 
> that not will in context tree?

You can certainly have top-level contexts that aren't children of
anything.  There's no real functional distinction between a context
created like that and one that is a child of TopMemoryContext, because
we never reset/delete children of TopMemoryContext anyway.  I was
careful to make all the other contexts descendants of TopMemoryContext
because I wanted to be able to call MemoryContextStats(TopMemoryContext)
to get a picture of all the memory usage.  Other than that
consideration, CacheMemoryContext, ErrorContext, and so forth could
perfectly well have been top-level contexts with no parent.

A context representing shared memory probably should be a top-level
context, though.  That would make sense if you think of TopMemoryContext
as the top-level of all the backend's *local* memory.

> Or skip for this specific variant context type independent
> MemoryContextCreate and init this common part itself? - (I vote for
> this)

No, certainly not.  Just pass a NULL for parent if you don't want to
connect it up to the local context tree.

>  Plan you some changes in SPI? I have new code for SPI save plan
> (per-context and via query cache). 

I have been wondering about that.  I don't like SPI saving plans in
TopMemoryContext because I don't think it knows how to get rid of them;
a plan saved there is effectively a permanent memory leak.  Not sure
what to do about it though.

> And last question, is current mcxt.c API final? I want port my query cache
> to compatible with current interface.  

I think it is done, though I reserve the right to change it if I find out
something needs to be done differently ;-).  But what I am expecting to
do next is just modify the planner and executor to make better use of
the facilities that are there now.  I won't need to change mcxt.c any
more unless I find it's too hard to use or doesn't do quite the right
things...
        regards, tom lane