Skip site navigation (1) Skip section navigation (2)

Re: Misc. consequences of backend memory management changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Misc. consequences of backend memory management changes
Date: 2000-06-29 01:37:35
Message-ID: 17891.962242655@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Adam WalczykiewiczDate: 2000-06-29 07:37:20
Subject: SPI - documentation
Previous:From: Bruce MomjianDate: 2000-06-29 01:19:04
Subject: Re: LC_MESSAGES and BSD/OS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group