On Jun 16, 2011, at 11:51 AM, Heikki Linnakangas wrote: > What's the current state of the POSIX shared memory patch? I grabbed the > patch from > http://archives.postgresql.org/message-id/d9edacf7-53f1-4355-84f8-2e74cd19d...@themactionfaction.com > and it doesn't seem to apply cleanly any more. Are you planning to continue > working on it? > > If I understood the conclusion of the discussions correctly, the current plan > is to continue using a small SysV shared memory segment for the interlock, > and POSIX shared memory for the rest. That lets us stay below SHMMAX even if > it's small, which is convenient for admins. Was there a conclusion on whether > we should use fnctl() to provide some extra safety in the current interlock > mechanism? I'm feeling that that should probably be split off to a separate > patch, it would be easier to review separately.
Hello, Please try a merge from my github branch: https://github.com/agentm/postgres/tree/posix_shmem I don't believe any conclusions were reached because the debate concerned whether or not fcntl locking was sufficient. I thought so while others pointed out that the proposed interlock would not work with mutli-client NFSv3 despite the fact that the current interlock doesn't either. I originally made the patch because SysV memory sometimes requires reboots which is especially annoying when expanding an existing production db server. Even if the next version of postgresql incorporates a hybrid SysV/POSIX shmem setup, reboots may still be required if one runs any other processes requiring SysV shmem (such as older versions of postgresql). In any case, I lost interest in maintaining the patch and would not object to having the patch removed from the CommitFest. Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
