Re: Misc. consequences of backend memory management changes

On Wed, 28 Jun 2000, Tom Lane wrote:

> 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?

For example I use AllocSet's block definition.

>
> > 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

Yes, I see, it is good idea.

> 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.

Well, the query cache shared memory pool and qCache_TopContext (parent of
all cache entry) are init during postmarter start up. In this time not exist
TopMemoryContext and 'node' for this context will alloc via malloc(). It is
right and I understand here. This qCache_TopContext is used for internal
query cache data and all data is in shmem.

*But* if I add entry to query cache I create for each entry separate memory
context and it must be in shared memory, but in shared memory must be not
only data allocated via this context, in shmem must be _all_ for context
relevant data --- so, context independent data too (bacause context must
overlive backend end). A problem is that common MemoryContextCreate() expects
that context 'node' is allocated in the TopMemoryContext or by force of
malloc(). Not is possible allocate context node in a parent context.

I read your comment "since the node must survive resets of its parent
context", but how resolve this?


I have two method for save cached planns. First in the hash table in shared
memory (about it we talking) and second in hash table in local memory. For
'local part' context I can set as parent CacheMemoryContext or will better
use TopMemoryConetxt.

> > 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.

We already told about it with Hiroshi. I rewrite SPI_sevaplan(), now it
save each plan to separate context and is possible use SPI_freeplan().
Also I add 'by_key' interface to SPI that allows save planns to the query
cache under some key (string or binary key). My SPI *not* use
TopMemoryContext.

Karel