Re: Misc. consequences of backend memory management changes

Karel Zak <zakkr(at)zf(dot)jcu(dot)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