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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
