Re: icps, shmmax and shmall - Shared Memory tuning - Mailing list pgsql-general

From Tom Lane
Subject Re: icps, shmmax and shmall - Shared Memory tuning
Date
Msg-id 13799.1020052039@sss.pgh.pa.us
Whole thread Raw
In response to Re: icps, shmmax and shmall - Shared Memory tuning  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: icps, shmmax and shmall - Shared Memory tuning
List pgsql-general
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sun, Apr 28, 2002 at 08:12:56PM -0400, Tom Lane wrote:
>> Sane kernels return an error on sbrk(2) if they don't have any more
>> memory to give out...

> The problem is that sbrk merely extends your memory map, the memory is not
> actually allocated until it is used, i.e. it's overcomitting memory.

And this is the application's fault?

If Linux overcommits memory, then Linux is broken.  Do not bother to
argue the point.  I shall recommend other Unixen to anyone who wants
to run reliable applications.  (HPUX for example; which has plenty of
faults, but at least it keeps track of how much space it can promise.)

            regards, tom lane

pgsql-general by date:

Previous
From: Michael Loftis
Date:
Subject: Re: intel vs amd benchmark for pg server part 2
Next
From: pgsql-gen Newsgroup (@Basebeans.com)
Date:
Subject: Re: intel vs amd benchmark for pg server part 2