Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I accept the "run from init.d" argument. So then, is there a case for
increasing the limits that initdb works with, to reflect the steep rise
we have seen in typically available memory at the low end?
I can't see any particular harm in having initdb try somewhat-larger
values ... but how far does that really go towards fixing the issues?
Personally, the default value I currently see as far too tight is
max_fsm_pages. I'd rather see initdb trying to push that up if it's
able to establish shared_buffers and max_connections at their current
maxima.
Ok. how would the logic go? Just have a function that runs max_fsm_pages
checks after we call test_connections() and test_buffers(), or should
there be some interplay between those settings? As I understand it, the
current setting would consume all of 120,000 bytes of shared memory, so
there could well be lots of head room.
... it would be nice to try to allow
one connection per standard allowed apache client (default is 256
non-threaded and 400 threaded, I think).
That's a mostly independent consideration, but it seems fair enough.
Can we check the exact values rather than relying on "I think"?
That's my reading of
http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxclients
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
