| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | dorian dorian <dorian37076(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: icps, shmmax and shmall - Shared Memory tuning |
| Date: | 2002-04-29 03:47:19 |
| Message-ID: | 13799.1020052039@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)svana(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | pgsql-gen Newsgroup (@Basebeans.com) | 2002-04-29 04:10:01 | Re: intel vs amd benchmark for pg server part 2 |
| Previous Message | Michael Loftis | 2002-04-29 02:18:36 | Re: intel vs amd benchmark for pg server part 2 |