shmmax tops out at 2G?

[Christian Peron]

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