Tom Lane wrote: > Curt Sampson <[EMAIL PROTECTED]> writes: > > So, while we're at it, what's the current state of people's thinking > > on using mmap rather than shared memory for data file buffers? > > There seem to be a couple of different threads in doc/TODO.detail/mmap. > > One envisions mmap as a one-for-one replacement for our current use of > SysV shared memory, the main selling point being to get out from under > kernels that don't have SysV support or have it configured too small. > This might be worth doing, and I think it'd be relatively easy to do > now that the shared memory support is isolated in one file and there's > provisions for selecting a shmem implementation at configure time. > The only thing you'd really have to think about is how to replace the > current behavior that uses shmem attach counts to discover whether any > old backends are left over from a previous crashed postmaster. I dunno > if mmap offers any comparable facility. > > The other discussion seemed to be considering how to mmap individual > data files right into backends' address space. I do not believe this > can possibly work, because of loss of control over visibility of data > changes to other backends, timing of write-backs, etc.
Agreed. Also, there was in intresting thread that mmap'ing /dev/zero is the same as anonmap for OS's that don't have anonmap. That should cover most of them. The only downside I can see is that SysV shared memory is locked into RAM on some/most OS's while mmap anon probably isn't. Locking in RAM is good in most cases, bad in others. This will also work well when we have non-SysV semaphore support, like Posix semaphores, so we would be able to run with no SysV stuff. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster