Re: Posix Shared Mem patch

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