On 02/07/2011 06:30 PM, Marti Raudsepp wrote:
On Mon, Feb 7, 2011 at 05:03, Craig Ringer<craig@xxxxxxxxxxxxxxxxxxxxx> wrote:
What would possibly help would be if Pg could fall back to lower
shared_buffers automatically, screaming about it in the logs but still
launching. OTOH, many people don't check the logs, so they'd think their
new setting had taken effect and it hadn't - you've traded one usability
problem for another. Even if Pg issued WARNING messages to each client
that connected, lots of (non-psql) clients don't display them, so many
users would never know.
Do you have a suggestion about how to do this better? The current
approach is known to be rather unlovely, but nobody's come up with a
better one that works reasonably and doesn't trample on other System V
shared memory users that may exist on the system.
We could do something similar to what Apache does -- provide distros
with a binary to check the configuration file in advance. This check
program is launched before the "restart" command, and if it fails, the
server is not restarted.
That would work for config file errors (and would probably be a good
idea) but won't help with bad shared memory configuration. When Pg is
already running, it's usually not possible for a test program to claim
the amount of shared memory the config file says to allocate, because Pg
is already using it. Nonetheless, Pg will work fine when restarted.
--
Craig Ringer
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
