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
-
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