On Wed, 15 Oct 2008, Gregory Stark wrote:
Greg Smith <gsmith@xxxxxxxxxxxxx> 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.
It happens when you run a utility designed to figure out if the application is compatible with your system and make corrections as it can to make it work properly. If you want something like that to be easy to use, the optimal approach to achieve that is to just barrel ahead and notify the admin what you did.
I'm pretty sure it would violate several Debian packaging rules.
You can wander to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=67481 to see one of the many times someone has tried to get the SHMMAX situation straightened out at the OS level. Quoth Martin Pitt: "Debian packages...must not alter kernel parameters at will; if they did, they would destroy each others settings.", followed by the standard wontfix for actually changing anything. They did at least improve the error reporting when the server won't start because of this problem there.
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?
If there were ever any Linux distributions that increased this value from the tiny default, you might have a defensible position here (maybe Oracle's RHEL fork does, they might do something here). I've certainly never seen anything besides Solaris ship with a sensible SHMMAX setting for database use on 2008 hardware out of the box. It's really quite odd, but as numerous probes in this area (from the above in 2000 to Peter's recent Linux bugzilla jaunt) show the resistance to making the OS default to any higher is considerable.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
