shmmax tops out at 2G?

[Garrett Cooper]

On Feb 23, 2009, at 11:08 AM, Christian Peron wrote:

> This issue has come up a number of times.  I was looking into fixing  
> this but I
> just have not had the time.  The basic issue is our shmid_ds  
> structure:
>
>     struct shmid_ds {
>         struct ipc_perm shm_perm;   /* operation permission  
> structure */
>         int             shm_segsz;  /* size of segment in bytes */
>         pid_t           shm_lpid;   /* process ID of last shared  
> memory op */
>         pid_t           shm_cpid;   /* process ID of creator */
>         short           shm_nattch; /* number of current attaches */
>         time_t          shm_atime;  /* time of last shmat() */
>         time_t          shm_dtime;  /* time of last shmdt() */
>         time_t          shm_ctime;  /* time of last change by  
> shmctl() */
>         void           *shm_internal; /* sysv stupidity */
>     };
>
>
> Basically the shm_segsz member needs to be switched from 32 bits  
> (int) to
> 64 bits.  The problem is that this breaks the ABI and older versions  
> of
> postgresql will not work.  The solution is to add additional syscalls.
>
> However, everytime this issue comes up, the question on whether we  
> should
> fix struct ipc_perm at the same time is asked.  The answer imho is  
> that
> we should, however this is more complex since semaphores, messaages  
> and
> shared memory segments all use it.
>
> The fixes are straight forward, however making sure we maintain  
> reverse
> compatability is where things become complicated, especially since  
> there
> are multiple layers of reverse compat we need to look after.
>
>
> On Mon, Feb 23, 2009 at 10:50:07AM -0500, Brian A. Seklecki 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
>>
>> Someone was nice enough to file a PR related to this:
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130274
>>
>> We'd be happy to sponsor development in -current to address this
>> limitation.  ~BAS

	Why isn't the field an unsigned int / size_t? I don't see much value  
in having the size be signed...
-Garrett