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

Re: Posix Shared Mem patch

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Posix Shared Mem patch
Date: 2012-06-26 22:12:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jun 26, 2012 at 2:53 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Daniel Farina's message of mar jun 26 17:40:16 -0400 2012:
>> 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 argument is what killed the original patch.  If you want to get
> anything done *at all* I think it needs to be dropped.  Changing shmem
> implementation is already difficult enough --- you don't need to add the
> requirement that the interlocking mechanism be changed simultaneously.
> You (or whoever else) can always work on that as a followup patch.

True, but then again, I did very intentionally write:

> Excerpts from Daniel Farina's message of mar jun 26 17:40:16 -0400 2012:
>> *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.

(Emphasis mine).

I don't think that -hackers at the time gave the zero-shmem rationale
much weight (I also was not that happy about the safety mechanism of
that patch), but upon more reflection (and taking into account *other*
software that may mangle shmem settings) I think it's something at
least worth thinking about again one more time.  What killed the patch
was an attachment to the deemed-less-safe stategy for avoiding bogus
shmem attachments already in it, but I don't seem to recall anyone
putting a whole lot of thought at the time into the zero-shmem case
from what I could read on the list, because a small interlock with
nattach seemed good-enough.

I'm simply suggesting that for additional benefits it may be worth
thinking about getting around nattach and thus SysV shmem, especially
with regard to safety, in an open-ended way.  Maybe there's a solution
(like Robert's FIFO suggestion?) that is not too onerous and can
satisfy everyone.


In response to


pgsql-hackers by date

Next:From: A.M.Date: 2012-06-26 22:15:48
Subject: Re: Posix Shared Mem patch
Previous:From: Tom LaneDate: 2012-06-26 22:12:19
Subject: Re: why roll-your-own s_lock? / improving scalability

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