From: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Posix Shared Mem patch |
Date: | 2012-06-26 22:15:48 |
Message-ID: | 9DB59B2A-01A3-4388-929E-70171083F3B1@themactionfaction.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 26, 2012, at 5:44 PM, Josh Berkus wrote:
>
>> 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.
This can be trivially reproduced if one runs an old (SysV shared memory-based) postgresql alongside a potentially newer postgresql with a smaller SysV segment. This can occur with applications that bundle postgresql as part of the app.
Cheers,
M
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-06-26 22:20:06 | Re: Posix Shared Mem patch |
Previous Message | Daniel Farina | 2012-06-26 22:12:41 | Re: Posix Shared Mem patch |