Thread: POSIX shared memory patch status
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-2E74CD19D22D@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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Thu, Jun 16, 2011 at 11:51 AM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 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-2E74CD19D22D@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. +1, emphatically. > 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. +1 for a separate patch. I see no reason why fixing that's got to be intertwined with this. It'd be relevant if we were planning to remove the current POSIX shm interlock, but so far nobody has offered a compelling explanation of why we should. The facility is supported pretty much everywhere; it's just the size limit that's a problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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-2E74CD19D22D@themactionfaction.comand it doesn't seem toapply 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 sharedmemory segment for the interlock, and POSIX shared memory for the rest. That lets us stay below SHMMAX even if it'ssmall, which is convenient for admins. Was there a conclusion on whether we should use fnctl() to provide some extrasafety in the current interlock mechanism? I'm feeling that that should probably be split off to a separate patch, itwould 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. Ithought so while others pointed out that the proposed interlock would not work with mutli-client NFSv3 despite the factthat the current interlock doesn't either. I originally made the patch because SysV memory sometimes requires reboots which is especially annoying when expanding anexisting production db server. Even if the next version of postgresql incorporates a hybrid SysV/POSIX shmem setup, rebootsmay 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
On 16.06.2011 20:22, A.M. wrote: > 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 despitethe fact that the current interlock doesn't either. > > I originally made the patch because SysV memory sometimes requires reboots which is especially annoying when expandingan existing production db server. Even if the next version of postgresql incorporates a hybrid SysV/POSIX shmemsetup, reboots may still be required if one runs any other processes requiring SysV shmem (such as older versions ofpostgresql). > > In any case, I lost interest in maintaining the patch and would not object to having the patch removed from the CommitFest. Ok, I'll mark this as "returned with feedback" then. Thanks for your efforts anyway! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com