Re: Changing the default configuration (was Re: - Mailing list pgsql-hackers

From Curt Sampson
Subject Re: Changing the default configuration (was Re:
Date
Msg-id Pine.NEB.4.51.0302131325430.1487@angelic.cynic.net
Whole thread Raw
In response to Re: Changing the default configuration (was Re:  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Changing the default configuration (was Re:  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Changing the default configuration (was Re:  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
On Wed, 12 Feb 2003, Bruce Momjian wrote:

> Christopher Kings-Lynne wrote:
>
> > You cannot change SHMMAX on the fly on FreeBSD.
>
> And part of the reason is because some/most BSD's map the page tables
> into physical RAM (kernel space) rather than use some shared page table
> mechanism. This is good because it prevents the shared memory from
> being swapped out (performance disaster).

Not at all! In all the BSDs, as far as I'm aware, SysV shared memory is
just normal mmap'd memory.

FreeBSD offers a sysctl that lets you mlock() that memory, and that is
helpful only because postgres insists on taking data blocks that are
already in memory, fully sharable amongst all back ends and ready to be
used, and making a copy of that data to be shared amongst all back ends.

> It doesn't actually allocate RAM unless someone needs it, but it does
> lock the shared memory into a specific fixed location for all processes.

I don't believe that the shared memory is not locked to a specific VM
address for every process. There's certainly no reason it needs to be.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC
 


pgsql-hackers by date:

Previous
From: Kevin Brown
Date:
Subject: Re: PostgreSQL Benchmarks
Next
From: Curt Sampson
Date:
Subject: Re: PostgreSQL Tuning Results