Re: Posix Shared Mem patch - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: Posix Shared Mem patch
Date
Msg-id CAAZKuFaDY9QkfgGS172OUu84rpkiYAV7soxwW6xnQYkSL9dBEQ@mail.gmail.com
Whole thread Raw
In response to Re: Posix Shared Mem patch  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Posix Shared Mem patch  (Josh Berkus <josh@agliodbs.com>)
Re: Posix Shared Mem patch  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Tue, Jun 26, 2012 at 2:18 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 6/26/12 2:13 PM, Robert Haas wrote:
>> On Tue, Jun 26, 2012 at 4:29 PM, Alvaro Herrera
>> <alvherre@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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proof concept - access to session variables on client side
Next
From: Robert Haas
Date:
Subject: Re: Posix Shared Mem patch