Re: Pre-allocation of shared memory ... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Pre-allocation of shared memory ...
Date
Msg-id 200306131325.h5DDPnI29011@candle.pha.pa.us
Whole thread Raw
In response to Re: Pre-allocation of shared memory ...  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Responses Re: Pre-allocation of shared memory ...  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
List pgsql-hackers
Patrick Welche wrote:
> On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > You have to love that swap + 1/2 ram option --- when you need four
> > > > possible options, there is something wrong with your approach.  :-)
> > > 
> > > I'm still wondering what the "no overcommit handling" option does,
> > > exactly.
> > 
> > I assume it does no kills, and allows you to commit until you run of of
> > swap and hang.  This might be the BSD 4.4 behavior, actually.
> 
> ? I thought the idea of no overcommit was that your malloc fails ENOMEM
> if there isn't enough memory free for your whole request, rather than
> gambling that other processes aren't actually using all of theirs right now
> and have pages swapped out. I don't see where the hang comes in..

I think there are two important memory cases:

malloc() - should fail right away if it can't reserve the requested
memory;  assuming application request memory they don't use just seems
dumb --- fix the bad apps.

fork() - this is the tricky one because you don't know at fork time who
is going to be sharing the data pages as read-only or doing an exec to
overlay a new process, and who is going to be modifying them and need a
private copy.

I think only the fork case is tricky.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Patrick Welche
Date:
Subject: Re: Pre-allocation of shared memory ...
Next
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: Pre-allocation of shared memory ...