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

  1. Distinguish wait-for-connection from wait-for-write-ready on Windows.

  2. Use asynchronous connect API in libpqwalreceiver