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: Noah Misch <noah@leadboat.com>
Cc: "Augustine, Jobin" <jobin.augustine@openscg.com>,
pgsql-bugs@postgresql.org
Date: 2017-08-06T15:17:57Z
Lists: pgsql-bugs, pgsql-hackers
Noah Misch <noah@leadboat.com> writes: > I've added this as an open item. Confirmed in this setup: > -- Client > Windows Server 2016 > postgresql-10.0-beta2-windows-x64-binaries.zip from EnterpriseDB I wonder whether the other complainants were using EDB's build, and if not, just what were they using. The indirect question is: what version of OpenSSL is the Windows build using? > I don't, however, see a smoking gun among commits. Would you bisect the > commits since 9.6 and see which one broke things? Gut instinct says that the reason this case fails when other tools can connect successfully is that libpqwalreceiver is the only tool that uses PQconnectStart/PQconnectPoll rather than a plain PQconnectdb, and that there is some behavioral difference between connectDBComplete's wait loop and libpqrcv_connect's wait loop that OpenSSL is sensitive to --- but only on Windows, and maybe only on particular OpenSSL versions. I have some memory of having tweaked libpqrcv_connect's loop once already, but I can't find a commit for that right now. A different line of thought is that maybe we broke it with the changes for OpenSSL 1.1.0. Again, it would be very important to know which OpenSSL version we're dealing with here. 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