From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Pre-allocation of shared memory ... |
Date: | 2003-06-13 13:25:49 |
Message-ID: | 200306131325.h5DDPnI29011@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Patrick Welche wrote:
> On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen T. Vermeulen | 2003-06-13 13:36:00 | Re: Pre-allocation of shared memory ... |
Previous Message | Patrick Welche | 2003-06-13 13:20:21 | Re: Pre-allocation of shared memory ... |