On Thu, Jun 28, 2012 at 6:05 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Jun 28, 2012 at 7:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Jun 27, 2012 at 9:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane <tgl@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