Re: Replication to Postgres 10 on Windows is broken
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Petr Jelinek <petr@2ndquadrant.com>, Peter Eisentraut <peter_e@gmx.net>, Noah Misch <noah@leadboat.com>, "Augustine, Jobin" <jobin.augustine@openscg.com>, pgsql-bugs@postgresql.org
Date: 2017-08-06T22:10:42Z
Lists: pgsql-bugs, pgsql-hackers
On 2017-08-06 18:04:49 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Here's a prototype patch implementing what Tom outlined. > > This bit is flat wrong: > > - int io_flag; > + int io_flag = WL_POSTMASTER_DEATH | WL_LATCH_SET; > > io_flag has to be *just* the I/O condition, because we use it in a test > after the WaitLatchOrSocket call. Hm, right. Wouldn't be particularly consequential, but... I'd actually consider just removing the if around /* If socket is ready, advance the libpq state machine */ if (rc & io_flag) status = PQconnectPoll(conn->streamConn); the only thing that protects us against is calling PQconnectPoll() when the latch has been set. Hardly problematic. > > Anybody have an opinion about adding ifs for WL_SOCKET_CONNECTED to > > !win32 implementations rather than redefining it to WL_SOCKET_WRITEABLE? > > I fear it would complicate matters greatly, because you'd have to figure > out which of the two flags to signal back after detecting socket writable. > I think defining it as equal to WL_SOCKET_WRITEABLE is fine. Well, I'd have said, signal the one(s) back that have been requested. But I'm ok with the current state, adding a bunch of pointless branches didn't strike me as worthwhile... Greetings, Andres Freund
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