Re: initdb profiles

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> 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