On Tue, Jun 26, 2012 at 2:53 PM, Alvaro Herrera <alvhe...@commandprompt.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. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
