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