Re: [HACKERS] 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: Peter Geoghegan <pg@bowt.ie>, Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, "Augustine, Jobin" <jobin.augustine@openscg.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-13T21:22:22Z
Lists: pgsql-bugs, pgsql-hackers
On 2017-08-13 16:55:33 -0400, Tom Lane wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > I think that it's useful for these things to be handled in an
> > adversarial manner, in the same way that litigation is adversarial in
> > a common law court. I doubt that Noah actually set out to demoralize
> > anyone. He is just doing the job he was assigned.
> 
> FWIW, I agree that Noah is just carrying out the RMT's task as
> assigned.

Well, then that's a sign that the tasks/process need to be rescoped.


> However, the only thing that Peter could really do about this of his own
> authority is to revert 1e8a850, which I certainly think should be the last
> resort not the first.  We are continuing to make progress towards finding
> a better solution, I think, and since no particular deadline is imminent
> we should let that process play out.

I agree that that'd be a bad fix. There's other things that should, but
don't, really use the asynchronous API, e.g. postgres_fdw.

As a measure of last restart we could add a libpq workaround that forces
a pqSocketCheck() at the right moment, while still establishing a
connection.  That's not good from an interruptability perspective, but
better than blocking for the entire connection establishment.

Greetings,

Andres Freund


Commits

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

  2. Use asynchronous connect API in libpqwalreceiver