Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Posix Shared Mem patch
Date: 2012-06-26 21:40:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jun 26, 2012 at 2:18 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 6/26/12 2:13 PM, Robert Haas wrote:
>> On Tue, Jun 26, 2012 at 4:29 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)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.


In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-06-26 21:41:44
Subject: Re: Posix Shared Mem patch
Previous:From: Tom LaneDate: 2012-06-26 21:29:33
Subject: Re: proof concept - access to session variables on client side

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group