Re: [PATCHES] default resource limits

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Maybe we need to split this into two pieces, given Tom's legitimate 
> concern about semaphore use. How about we increase the allowed range for 
> shared_buffers and max_fsm_pages, as proposed in my patch, and leave the 
> max_connections issue on the table? I also wondered if instead of first 
> setting max_connections and then shared_buffers/max_fsm_pages, we should 
> try to scale them in synch somehow.

The existing initdb code actually does try to scale them in sync to some
extent --- take a closer look at the arguments being passed during the
max-connections test phase.  It won't choose a large max_connections
unless it can simultaneously get 5 times that many shared_buffers.
I think this probably needs to be more aggressive though.  In a
situation of limited SHMMAX it's probably more important to keep
shared_buffers as high as we can than to get a high max_connections.
We could think about increasing the 5x multiplier, adding Min and/or Max
limits, or some combination.

BTW, I fat-fingered the calculations I was doing last night --- the
actual shmem consumption in CVS tip seems to be more like 17K per
max_connection increment, assuming max_locks_per_connection = 64.

			regards, tom lane