Re: Proposal for fixing intra-query memory leaks

On Tue, 2 May 2000, Tom Lane wrote:

> Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> >> (Is there any value in allowing for other memory context types? We could
>
> > I have "aset" variant, that allow create and work with memory context in
> > a shared memory.
>
> Hmm. Well, maybe nailing things down to a single kind of context is
> pushing it too far. What I mainly want is to be able to free a palloc'd
> chunk without assuming that it came from the currently active context.

With my QueryCache contexts it will possible too. I use same AllocSet
structs - different is only a block spring (not from malloc, but from
QueryCache shmem pool). Change chunks headers will easy if it will need.

A problem will, how select right method for free/realloc. This information
is only in context struct, but not in a chunk header or in AllocSet struct
(now).

> With AllocSets as aset.c does them, this is possible because every chunk
> has a back-link to its owning context. We could still make it work with
> multiple context types if we require that they all have the same kind of
> back-link in the same place. Essentially, the overhead data for an
> allocated chunk would have to be the same for all context types. But
> we could still have different context types with different allocation
> methods for each type. pfree macro would get the back-link from 8 bytes
> before the given chunk address, verify that it points at something with

OK. You need in chunk header chunk-size too, not the back-to-context-link
only.

> the right node type to be a memory context header, and then call through
> a function pointer in the context header to get to the routine that
> actually knows how to free a chunk of that context type.

The idea it is very good, because if we will work with more context and
allocations types we need identify chunks.

The chunk header must be relevant and same for all allocation methods and
must be independent on AllocSel (aset.c) code. Now, it is not. Am I right?

> Good point. I don't believe that contexts have names at all at the
> moment (portals do, but not contexts). But it seems like it would be
> helpful for debugging to have some kind of name for each context. It
> wouldn't have to be unique or anything, but when you were trying to
> figure out where your memory leak is, being able to see which context
> has gotten bloated would be useful...

Well, but not expect that header must be static string, better will
_allocate_ it in a CreateContext() function.

Karel