Re: Replication to Postgres 10 on Windows is broken
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>,
"Augustine,
Jobin" <jobin.augustine@openscg.com>,
pgsql-bugs@postgresql.org
Date: 2017-08-06T17:34:42Z
Lists: pgsql-bugs, pgsql-hackers
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
Commits
-
Distinguish wait-for-connection from wait-for-write-ready on Windows.
- d7ab908fbab5 10.0 landed
- f3a4d7e7c290 11.0 landed
-
Use asynchronous connect API in libpqwalreceiver
- 1e8a85009447 10.0 cited