On Wednesday, June 27, 2012 05:28:14 AM Robert Haas wrote:
> On Tue, Jun 26, 2012 at 6:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Josh Berkus <josh@agliodbs.com> writes:
> >> So let's fix the 80% case with something we feel confident in, and then
> >> revisit the no-sysv interlock as a separate patch. That way if we can't
> >> fix the interlock issues, we still have a reduced-shmem version of
> >> Postgres.
> >
> > Yes. Insisting that we have the whole change in one patch is a good way
> > to prevent any forward progress from happening. As Alvaro noted, there
> > are plenty of issues to resolve without trying to change the interlock
> > mechanism at the same time.
>
> So, here's a patch. Instead of using POSIX shmem, I just took the
> expedient of using mmap() to map a block of MAP_SHARED|MAP_ANONYMOUS
> memory. The sysv shm is still allocated, but it's just a copy of
> PGShmemHeader; the "real" shared memory is the anonymous block. This
> won't work if EXEC_BACKEND is defined so it just falls back on
> straight sysv shm in that case.
>
> There are obviously some portability issues here - this is documented
> not to work on Linux <= 2.4, but it's not clear whether it fails with
> some suitable error code or just pretends to work and does the wrong
> thing. I tested that it does compile and work on both Linux 3.2.6 and
> MacOS X 10.6.8. And the comments probably need work and... who knows
> what else is wrong. But, thoughts?
Btw, RhodiumToad/Andrew Gierth on irc talked about a reason why sysv shared
memory might be advantageous on some platforms. E.g. on freebsd there is the
kern.ipc.shm_use_phys setting which prevents paging out shared memory and also
seems to make tlb translation cheaper. There does not seem to exist an
alternative for anonymous mmap.
So maybe we should make that a config option?
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services