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

Re: dynamically allocating chunks from shared memory

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamically allocating chunks from shared memory
Date: 2010-07-20 17:50:20
Message-ID: 1279647881-sup-2390@alvh.no-ip.org (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
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).

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-07-20 17:51:36
Subject: Re: managing git disk space usage
Previous:From: Aidan Van DykDate: 2010-07-20 17:28:07
Subject: Re: managing git disk space usage

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