Re: Re: SOMAXCONN (was Re: Solaris source code) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: SOMAXCONN (was Re: Solaris source code)
Date
Msg-id 23627.994868803@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: SOMAXCONN (was Re: Solaris source code)  (Peter Eisentraut <peter_e@gmx.net>)
Responses 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))
List 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 by date:

Previous
From: Jan Wieck
Date:
Subject: Re: varchar vs. text
Next
From: Bruce Momjian
Date:
Subject: Re: Re: SOMAXCONN (was Re: Solaris source code)