(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 20 Aug 2008 05:58:57 -0700 (PDT)

I don't think anybody has even thought about the shmmax default in
years.  Sure, it might be time to reexamine that.

It would be useful to get distro input on this.  Do they override the
kernel default at boot time?  If so, what do they do?


Also, from a quick read it looks to me that shmmax is busted in the
non-init namespace.

clone_ipc_ns() calls shm_init_ns() which does

	ns->shm_ctlmax = SHMMAX;

which a) fails to inherit the parent's setting and b) cannot be altered
from SHMMAX via the sysctl?

--

[ message continues ]

This is debatable if such behaviour should be default, this makes one ipc_ns

It can be altered. See kludge called get_ipc().

(well, I haven't checked personally, but it's a bug if IPC sysctls
aren't independently controllable after CLONE_NEWIPC, complain loudly).

--

[ message continues ]

Oh, I forgot for a moment, that mainline has hierarchical ipc_ns.

--

[ message continues ]

Red Hat provide a sysctl tuning config file and I believe things like the
Oracle install docs cover this.

There is btw no earthly reason why a postgres package can't include a
tool to do this or postgres can't check and update it as part of its
own set up and config file options


Alan
--

[ message continues ]

I have explored this, it would be possible, but it would be a pain in the 
neck.  You'd need to add an option to postgres to print out how much shared 
memory you would need for a given configuration (because there are multiple 
factors in this), run this across all postgres instances on the machine, sum 
it up, then arrange for this to be fed back to sysctl or pasted back into 
sysctl.conf, being careful not to override or lower an existing setting that 
might have wanted to reserve space for other things.  Note that to make this 
robust you would have to rerun this after every configuration change + 
restart cycle across all postgres instances on the machine, race conditions 
included.  And you'd probably violate a few packaging guidelines on the way.  
Plus, this would have to be distro-specific (not Linux-specific, but 
distro-specific), doesn't help managed hosting with no root access, and 
doesn't help people building from source.  So altogether it is very 
complicated.

In the meantime I am trying to explore why the shmmax default is what it is.  
Or why it has to exist at all.  If we can figure that out, maybe we can solve 
a lot of users a lot of trouble with much less effort (including Oracle 
users, why not).
--

[ message continues ]

Debian and Ubuntu have a sysctl.conf that is processed at boot time, but it 
does not contain anything related to shm* by default.

Suse has a sysctl.conf, but it is not processed at boot by default.  You have 
to activate a special boot service in the runlevel system to make it actually 
run at boot.  (Try explaining that to a PostgreSQL user.)  There is nothing 
related to shm* in the default configuration.
--

[ message continues ]