Re: Replication to Postgres 10 on Windows is broken
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Augustine, Jobin" <jobin.augustine@openscg.com>, pgsql-bugs@postgresql.org
Date: 2017-08-06T15:50:37Z
Lists: pgsql-bugs, pgsql-hackers
On Sun, Aug 06, 2017 at 11:17:57AM -0400, Tom Lane wrote: > 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? Those binaries I used have OpenSSL 1.0.2l. > > 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 That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree callers outside of libpq itself. > OpenSSL is sensitive to --- but only on Windows, and maybe only on > particular OpenSSL versions. The failure is so early, before pgtls_init(), that I doubt OpenSSL version is a factor.
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