On 06/26/2012 07:15 PM, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mar jun 26 18:58:45 -0400 2012:
Even if you actively try to configure the shmem settings to exactly
fill shmmax (which I concede some installation scripts might do),
it's going to be hard to do because of the 8K granularity of the main
knob, shared_buffers.
Actually it's very easy -- just try to start postmaster on a system with
not enough shmmax and it will tell you how much shmem it wants. Then
copy that number verbatim in the config file. This might fail on picky
systems such as MacOSX that require some exact multiple or power of some
other parameter, but it works fine on Linux.
Except that we have to account for other installers. A user can install
an application in the future which clobbers the value and then the
original application will fail to run. The options to get the first app
working is:
a) to re-install the first app (potentially preventing the second app
from running)
b) to have the first app detect the failure and readjust the value
(guessing what it should be) and potentially forcing a reboot
c) to have the the user manually adjust the value and potentially force
a reboot
The failure usually gets blamed on the first application.
That's why we had to nuke SysV shmem.
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
