shmmax tops out at 2G?

[John Baldwin]

On Wednesday 13 December 2006 13:34, Peter Jeremy wrote:
> On Wed, 2006-Dec-13 10:50:21 -0500, Bill Moran wrote:
> >In response to Bill Moran <wmoran at collaborativefusion.com>:
> >> sysctl kern.ipc.shmmax=2200000000
> >> kern.ipc.shmmax: 2100000000 -> -2094967296
> >> 
> >> Looks like an unsigned 32-bit int.  That doesn't seem to scale as well as
> >> would be expected on 64-bit arch (or PAE for that matter).
> >> 
> >> Is this a mistake, or intentional?  I'm working with some big memory
> >> systems, and I sure would like to allocate more than 2G for PostgreSQL
> >> to use ...
> 
> I thought POSIX specified 'int' but I may be mis-remembering.  Tru64
> uses int (and 2GB max) whilst Solaris allows 64-bit values.
> Logically, shm_segsz and shm{min,max} should be intptr_t, shmall is
> less clear but probably should be similar.

Actually, unless you are holding a pointer, it should be size_t.  size_t is 
also the same size as a pointer (in practice), but it's for the size of 
objects in memory (i.e. what sizeof() returns), so I do think size_t is more 
appropriate.  The painful thing here will be destroying the SYSVIPC ABI on 
64-bit archs.  Bill, you should go talk to Robert Watson and time it with him 
as he wants to fix SYSVIPC to use uid_t which breaks the ABI, and if we're 
going to break the ABI, we should do it all at once. :)

-- 
John Baldwin