From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Ian Lance Taylor <ian(at)zembu(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: SOMAXCONN (was Re: Solaris source code) |
Date: | 2001-07-11 16:26:43 |
Message-ID: | 23627.994868803@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-07-11 17:00:42 | Re: Re: Encrypting pg_shadow passwords |
Previous Message | Jan Wieck | 2001-07-11 16:17:12 | Re: varchar vs. text |