On Tue, Jun 26, 2012 at 6:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Josh Berkus <j...@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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
anonymous-shmem.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
