Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

From: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Posix Shared Mem patch
Date: 2012-06-28 13:47:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


In response to


pgsql-hackers by date

Next:From: Noah MischDate: 2012-06-28 13:48:58
Subject: Re: pg_signal_backend() asymmetry
Previous:From: Robert HaasDate: 2012-06-28 13:46:27
Subject: Re: Event Triggers reduced, v1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group