Re: Cygwin PostgreSQL Regression Test Problems (Revisited)
От | Tom Lane |
---|---|
Тема | Re: Cygwin PostgreSQL Regression Test Problems (Revisited) |
Дата | |
Msg-id | 8565.986233454@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Cygwin PostgreSQL Regression Test Problems (Revisited) (Jason Tishler <Jason.Tishler@dothill.com>) |
Ответы |
Re: Cygwin PostgreSQL Regression Test Problems (Revisited)
|
Список | pgsql-ports |
Jason Tishler <Jason.Tishler@dothill.com> writes: > In both cases there are no hangs, just the error messages are different. > Unfortunately, for the non-blocking case the error message is cryptic. > I tried tracking down error "10061" which comes from getsockopt(), but > I was unsuccessful. Is there any way to improve the readability of this > error message? I'm inclined to leave the blocking-connect change in there just to suppress that peculiar error message. No, I have no idea where it's coming from, either. >> However Hiroshi says later that he already tried [ raising SOMAXCONN ] > Even if it worked, this would have just pushed the problem instead of > really fixing it. If the problem were overflow of the accept queue, then raising the listen() parameter ought to fix it, assuming that Windows does actually allow larger values for the parameter. Given that we are only hearing this problem reported on Windows, I have a sneaking suspicion that the effective queue length limit is 1 on that platform no matter what we pass to listen(). Is there anyone we might ask about concurrent connection-request handling on Windows? regards, tom lane
В списке pgsql-ports по дате отправления: