Re: PQConnectPoll, connect(2), EWOULDBLOCK and somaxconn

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PQConnectPoll, connect(2), EWOULDBLOCK and somaxconn
Дата
Msg-id 1681.1372291660@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PQConnectPoll, connect(2), EWOULDBLOCK and somaxconn  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: PQConnectPoll, connect(2), EWOULDBLOCK and somaxconn  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-06-26 12:07:54 -0400, Tom Lane wrote:
>> ... I wonder whether it's safe to remove the case altogether.  Could
>> anyone research the situation for non-blocking connect() on Windows?
>> Perhaps on Windows we shouldn't test for EINPROGRESS at all?

> The way EWOULDBLOCK is mentioned on msdn
> (http://msdn.microsoft.com/en-us/library/windows/desktop/ms737625%28v=vs.85%29.aspx)
> it indeed seems to be required.

Yeah, that seems pretty clear: WSAEWOULDBLOCK is what's returned when a
nonblocking connect() has been started successfully.

> I don't see how we could trigger the conditions for EINPROGRESS on
> windows that msdn lists, but since we need it on unixoid systems and its
> valid to treat the connect as partiall successfull on windows, there
> seems little benefit in dropping it.

I was about to argue for removing the EINPROGRESS check on Windows,
on the grounds that this would be the same type of bug as you're
complaining of on Linux, ie, if the call does return this error we'll
mistakenly think the connection is in progress and go on to deliver an
unhelpful failure message later.

However, some more trolling of the intertubes suggests that Cygwin's
emulation of socket() does indeed return EINPROGRESS; see for instance
this ancient thread of ours:

http://www.postgresql.org/message-id/flat/14855.49635.565990.716645@kryten.bedford.waii.com#14855.49635.565990.716645@kryten.bedford.waii.com
Unless we want to distinguish Cygwin from native Windows in this code
chunk, maybe we'd better leave well enough alone.

I still want to delete the test for SOCK_ERRNO == 0.  I traced that back
to commit da9501bddb42222dc33c031b1db6ce2133bcee7b, but I can't find
anything in the mailing list archives to explain that.  I have an
inquiry in to Jan to see if he can remember the reason ...
        regards, tom lane



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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: MemoryContextAllocHuge(): selectively bypassing MaxAllocSize
Следующее
От: gabrielle
Дата:
Сообщение: Re: Kudos for Reviewers -- straw poll