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
postgresqlwith a smaller SysV segment. This can occur with applications that bundle postgresql as part of the app.
Cheers,
M
