Re: Replication to Postgres 10 on Windows is broken

Hi,

On 2017-08-06 13:34:42 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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.

Right, that's what I went on to say ;)

> 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.

Yea, that should work, and could be useful-ish for things outside of
libpqwalreceiver. E.g. parallel fdw scan, that IIRC somebody is working
on, seems like it very well could run into similar issues if we want to
handle interrupts, which we should...

> * 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...)

Let's use proper ifs ;)...

Greetings,

Andres Freund