Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken |
Дата | |
Msg-id | 20170813212222.x7xhjjtjddkvgr3s@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken
Re: [HACKERS] [BUGS] Replication to Postgres 10 on Windows is broken |
Список | 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
В списке pgsql-hackers по дате отправления: