Re: [HACKERS] Replication to Postgres 10 on Windows is broken
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
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:35:43Z
Lists: pgsql-bugs, pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > 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. Probably a better idea is to fix things so that can't-send-yet results in returning PGRES_POLLING_WRITING rather than a failure. That would result in a busy-wait in this scenario on Windows, which is arguably better than blocking. It would also make this part of libpq more robust against applications being sloppy about socket readiness checks (which, you could argue, is exactly what libpqwalreceiver is being). But it would be a somewhat ticklish change because of the portability hazards, so I'm really disinclined to do it this late in beta. 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