Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> 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.
Yes, I know. What I meant was that we could try using one phase
rather than two. But that's only one possible approach.
> 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.
>
Yes. If we were to base it on the current maxima (1000/100), we could use a
factor of 10, or if on the maxima I am now proposing (4000/250) a factor of
16. Something in that range is about right I suspect.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
