Andres Freund <andres@anarazel.de> writes:
> On 2017-08-06 12:29:07 -0400, Tom Lane wrote:
>> This is problematic, because the APIs in between don't provide a way
>> to report that we're still waiting for connect rather than for
>> data-write-ready. Anybody have the stomach for extending PQconnectPoll's
>> API with an extra PGRES_POLLING_CONNECTING state?
> I'm a bit hesitant to do so at this phase of the release cycle,
I'm pretty hesitant to do that at *any* phase of the release cycle,
it's just too likely to break user code.
However, there's always more than one way to skin the cat. What we need
to know is whether PQconnectPoll's state machine is in CONNECTION_STARTED
state, and PQstatus() does expose that, even though it claims it's an
internal state that callers shouldn't rely on. So here's a sketch:
* Invent a separate WL_SOCKET_CONNECTED flag for WaitLatchOrSocket.
On Unix we can treat that the same as WL_SOCKET_WRITEABLE, on Windows
it maps to FD_CONNECT.
* In libpqwalreceiver, do something like
io_flag = (status == PGRES_POLLING_READING ? WL_SOCKET_READABLE
#ifdef WIN32 : PQstatus(conn->streamConn) == CONNECTION_STARTED ? WL_SOCKET_CONNECTED
#endif : WL_SOCKET_WRITEABLE);
The #ifdef's optional, but no reason to spend extra cycles if we don't
have to. (Not sure if this is adequately parenthesized...)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs