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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2012-06-26 21:44:42 | Re: why roll-your-own s_lock? / improving scalability |
Previous Message | Robert Haas | 2012-06-26 21:41:44 | Re: Posix Shared Mem patch |