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 Misch||Date: 2012-06-28 13:48:58|
|Subject: Re: pg_signal_backend() asymmetry|
|Previous:||From: Robert Haas||Date: 2012-06-28 13:46:27|
|Subject: Re: Event Triggers reduced, v1|