On Thu, Jun 28, 2012 at 6:05 AM, Magnus Hagander <mag...@hagander.net> wrote: > On Thu, Jun 28, 2012 at 7:00 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Jun 27, 2012 at 9:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@gmail.com> writes: >>>> On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>>> Would Posix shmem help with that at all? Why did you choose not to >>>>> use the Posix API, anyway? >>> >>>> It seemed more complicated. If we use the POSIX API, we've got to >>>> have code to find a non-colliding name for the shm, and we've got to >>>> arrange to clean it up at process exit. Anonymous shm doesn't require >>>> a name and goes away automatically when it's no longer in use. >>> >>> I see. Those are pretty good reasons ... >> >> So, should we do it this way? >> >> I did a little research and discovered that Linux 2.3.51 (released >> 3/11/2000) apparently returns EINVAL for MAP_SHARED|MAP_ANONYMOUS. >> That combination is documented to work beginning in Linux 2.4.0. How >> worried should we be about people trying to run PostgreSQL 9.3 on >> pre-2.4 kernels? If we want to worry about it, we could try mapping a >> one-page shared MAP_SHARED|MAP_ANONYMOUS segment first. If that >> works, we could assume that we have a working MAP_SHARED|MAP_ANONYMOUS >> facility and try to allocate the whole segment plus a minimal sysv >> shm. If the single page allocation fails with EINVAL, we could fall >> back to allocating the entire segment as sysv shm.
Why not just mmap /dev/zero (MAP_SHARED but not MAP_ANONYMOUS)? I seem to think that's what I did when I needed this functionality oh so many moons ago. -- Jon -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers