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

Re: Posix Shared Mem patch

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Daniel Farina <daniel(at)heroku(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:44:13
Message-ID: 4FEA2D2D.1070008@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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.

Personally, I see this as rather an extreme case, and aside from AgentM
himself, have never run into it before.  Certainly it would be useful to
not need SysV RAM at all, but it's more important to get a working patch
for 9.3.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



In response to

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2012-06-26 21:44:42
Subject: Re: why roll-your-own s_lock? / improving scalability
Previous:From: Robert HaasDate: 2012-06-26 21:41:44
Subject: Re: Posix Shared Mem patch

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