Re: Re: SOMAXCONN (was Re: Solaris source code)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: SOMAXCONN (was Re: Solaris source code)
Дата
Msg-id 23627.994868803@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: SOMAXCONN (was Re: Solaris source code)  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Re: SOMAXCONN (was Re: Solaris source code)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re: SOMAXCONN (was Re: Solaris source code)  (ncm@zembu.com (Nathan Myers))
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Right.  Okay, it seems like just making it a hand-configurable entry
>> in config.h.in is good enough for now.  When and if we find that
>> that's inadequate in a real-world situation, we can improve on it...

> Would anything computed from the maximum number of allowed connections
> make sense?

[ looks at code ... ]  Hmm, MaxBackends is indeed set before we arrive
at the listen(), so it'd be possible to use MaxBackends to compute the
parameter.  Offhand I would think that MaxBackends or at most
2*MaxBackends would be a reasonable value.

Question, though: is this better than having a hardwired constant?
The only case I can think of where it might not be is if some platform
out there throws an error from listen() when the parameter is too large
for it, rather than silently reducing the value to what it can handle.
A value set in config.h.in would be simpler to adapt for such a platform.

BTW, while I'm thinking about it: why doesn't pqcomm.c test for a
failure return from the listen() call?  Is this just an oversight,
or is there a good reason to ignore errors?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: varchar vs. text
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: SOMAXCONN (was Re: Solaris source code)