Excerpts from Markus Wanner's message of vie jul 02 19:44:46 -0400 2010:
> Having written a very primitive kind of a dynamic memory allocator for
> imessages [1], I've always wanted a better alternative. So I've
> investigated a bit, refactored step-by-step, and finally came up with
> the attached, lock based dynamic shared memory allocator. Its interface
> is as simple as malloc() and free(). A restart of the postmaster should
> truncate the whole area.
Interesting, thanks.
I gave it a skim and found that it badly needs a lot more code comments.
I'm also unconvinced that spinlocks are the best locking primitive here.
Why not lwlocks?
> Being a component which needs to pre-allocate its area in shared memory
> in advance, you need to define a maximum size for the pool of
> dynamically allocatable memory. That's currently defined in shmem.h
> instead of a GUC.
This should be an easy change; I agree that it needs to be configurable.
I'm not sure what kind of resistance you'll see to the idea of a
dynamically allocatable shmem area. Maybe we could use this in other
areas such as allocating space for heavyweight lock objects. Right now
the memory usage for them could grow due to a transitory increase in
lock traffic, leading to out-of-memory conditions later in other
modules. We've seen reports of that problem, so it'd be nice to be able
to fix that with this infrastructure.
I didn't look at the imessages patch (except to notice that I didn't
very much like the handling of out-of-memory, but you already knew that).