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.

>int shmget(key_t, size_t, int);
>
>I appears as if those values should have been size_t all along.  I'm
>_assuming_ that the return value is an identifier and not a memory
>address, which is what the docs seem to imply.

shmget() returns an "id" that uniquely refers to a shared memory
segment (stupidly designed SysV IPC namespace) and shmat() takes
the "id" and returns the address.

>So, my first thought is that all the int values in those structures
>should be changed to size_t.  If I understand the use of that type
>correctly, it should always be the native word size on the architecture,

I believe intptr_t is more logical - an integer size that is the
same size as a pointer.  Unfortunately, as I mentioned above, some
of this is specified in "standards" and logic is usually only present
by accident in such documents.

>but will that make this work for PAE as well, or should those be
>changed to uint64_t so they're 8 bits wide on all archs?

PAE is kernel only - userland still sees only 32 bits.  (You can
fit more RAM into the box, but each process is still limited to
4GB - KVM size).  Don't unnecessarily use [u]int64_t as it is
comparatively inefficient on 32-bit architectures.

I know Oracle (at least) avoids the problem on Tru64 by using
multiple SHM segments to allow SGA exceeding 2GB.
-- 
Peter Jeremy

Attachment: pgpSILO7IEYU0.pgp
Description: PGP signature

Reply via email to