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 <[EMAIL PROTECTED]>:
> >> 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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
