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

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

  2. Use asynchronous connect API in libpqwalreceiver