Re: Pre-allocation of shared memory ...

http://lwn.net/Articles/4628/ has this possibly useful info:

---------------
So what is strict VM overcommit? We introduce new overcommit policies
that attempt to never succeed an allocation that can not be fulfilled by
the backing store and consequently never OOM. This is achieved through
strict accounting of the committed address space and a policy to
allow/refuse allocations based on that accounting.

In the strictest of modes, it should be impossible to allocate more
memory than available and impossible to OOM. All memory failures should
be pushed down to the allocation routines -- malloc, mmap, etc.
--------------
But see also the discussion from July last
year:http://www.ussg.iu.edu/hypermail/linux/kernel/0207.2/index.htmlA quick
investigation of 2.4 releases on kernel.org appears to show this still
hasn't made it into mainline kernels. Apparently Alan did this work
originally because RH had customers using Oracle who were running into OOM
... Surprise!I don't keep copies of old kernel sources around on my Linux
machine, so I don't know when it went into the RH kernel series - that at
least would be nice to know.andrew

----- Original Message -----
From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: <pgsql-hackers(at)postgresql(dot)org>
Sent: Saturday, June 14, 2003 12:30 PM
Subject: Re: [HACKERS] Pre-allocation of shared memory ...

> The trouble with this advice is that if I am an SA wanting to run a DBMS
> server, I will want to run a kernel supplied by a vendor, not an arbitrary
> kernel released by a developer, even one as respected as Alan Cox.
>
> andrew
>
> ----- Original Message -----
> From: "Lamar Owen" <lamar(dot)owen(at)wgcr(dot)org>
> To: "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
> Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>; <pgsql-hackers(at)postgresql(dot)org>
> Sent: Saturday, June 14, 2003 11:52 AM
> Subject: Re: [HACKERS] Pre-allocation of shared memory ...
>
>
> > On Friday 13 June 2003 15:29, Lamar Owen wrote:
> > > It is or was a Linux kernel problem. The 2.2 kernel required double
> swap
> > > space, even though it wasn't well documented. Early 2.4 kernels also
> > > required double swap space, and it was better documented. Current Red
> Hat
> > > 2.4 kernels, I'm not sure which VM system is in use. The old VM
> certainly
> > > DID require double physical memory swap space.
> >
> > After consulting with some kernel gurus, you can upgrade to a straight
> Alan
> > Cox (-ac) kernel and turn off overcommits to cause it to fail the
> allocation
> > instead of blowing processes out at random when the overcommit bites.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match