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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
