Greg Smith <gsmith@gregsmith.com> writes:
> DB2 has automatically updated the "shmmax" kernel
> parameter from "33554432" to the recommended value "268435456".
This seems like a bogus thing for an application to do though. The Redhat
people seem happy with the idea but I'm pretty sure it would violate several
Debian packaging rules. Generally it seems crazy for a distribution to ship
configured one way by default but have packages change that behind the user's
back. What if the admin set SHMMAX that way because he wanted it? What happens
when a new distribution package has a new default but doesn't adjust it
because it sees the "admin" has changed it -- even though it was actually
Postgres which made the change?
> And you're off--it bumped that from the default 32MB to 256MB. The problem for
> PostgreSQL is that nobody who is motivated enough to write such magic for a
> large chunk of the supported platforms has had the time to do it yet. I'll get
> to that myself eventually even if nobody else does, as this is a recurring
> problem I'd like to make go away.
ISTM the right way to make it go away is to allocate temporary files and mmap
them instead of using sysv shared memory. Then we can mmap as much as we want.
Before we lose root privileges we can even mlock as much as we want.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
