On 11/08/2010 17:34, Greg Smith wrote:
> The problem here is that the amount of shared memory a system can
> allocate is hard to discover any other way than starting the server and
> seeing if it works. So doing what you advise will leave the database
> unable to start on any system that hasn't gotten the right OS kernel
> tweaks done first.
Well, is that true under Windows, too? I think we need to cover Windows,
here.
Under unix, having postgresql start correctly is a concern of the
distribution vendor. Even if the guessing isn't bullet-proof, the vendor
either knows how to configure the kernel to have the 'auto' thing work,
or is able to provide its own postgresql.conf.
Sure, there are people who download and compile, but I don't think they
are afraid of editing postgresql.conf should the server fail to start.
Also, I'd say this is a case where it's much better to fail with a
message "listen buddy, your server has 64GB of RAM installed but your
kernel is configured for 20MB of shared memory only, you should really
increase it", rather than start successfully but with very poor
performance. It's a matter of correctness: I see PG as a high
performance database system. Allowing to start it in awfully suboptimal
conditions it's no different from allowing '0000-00-00' as a date: it
may give you the idea you did the right thing, but most of the time you
didn't.
.TM.