On Tue, Jun 26, 2012 at 2:18 PM, Josh Berkus <j...@agliodbs.com> wrote: > On 6/26/12 2:13 PM, Robert Haas wrote: >> On Tue, Jun 26, 2012 at 4:29 PM, Alvaro Herrera >> <alvhe...@commandprompt.com> wrote: >>> Excerpts from Josh Berkus's message of mar jun 26 15:49:59 -0400 2012: >>>> Robert, all: >>>> >>>> Last I checked, we had a reasonably acceptable patch to use mostly Posix >>>> Shared mem with a very small sysv ram partition. Is there anything >>>> keeping this from going into 9.3? It would eliminate a major >>>> configuration headache for our users. >>> >>> I don't think that patch was all that reasonable. It needed work, and >>> in any case it needs a rebase because it was pretty old. >> >> Yep, agreed. >> >> I'd like to get this fixed too, but it hasn't made it up to the top of >> my list of things to worry about. > > Was there a post-AgentM version of the patch, which incorporated the > small SySV RAM partition? I'm not finding it.
On that, I used to be of the opinion that this is a good compromise (a small amount of interlock space, plus mostly posix shmem), but I've heard since then (I think via AgentM indirectly, but I'm not sure) that there are cases where even the small SysV segment can cause problems -- notably when other software tweaks shared memory settings on behalf of a user, but only leaves just-enough for the software being installed. This is most likely on platforms that don't have a high SysV shmem limit by default, so installers all feel the prerogative to increase the limit, but there's no great answer for how to compose a series of such installations. It only takes one installer that says "whatever, I'm just catenating stuff to sysctl.conf that works for me" to sabotage Postgres' ability to start. So there may be a benefit in finding a way to have no SysV memory at all. I wouldn't let perfect be the enemy of good to make progress here, but it appears this was a witnessed real problem, so it may be worth reconsidering if there is a way we can safely remove all SysV by finding an alternative to the nattach mechanic. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
