Re: Keepalive for max_standby_delay
От | Simon Riggs |
---|---|
Тема | Re: Keepalive for max_standby_delay |
Дата | |
Msg-id | 1275503257.21465.2805.camel@ebony обсуждение исходный текст |
Ответ на | Re: Keepalive for max_standby_delay (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Keepalive for max_standby_delay
Re: Keepalive for max_standby_delay |
Список | pgsql-hackers |
On Wed, 2010-06-02 at 13:14 -0400, Tom Lane wrote: > This patch seems to me to be going in fundamentally the wrong direction. > It's adding complexity and overhead (far more than is needed), and it's > failing utterly to resolve the objections that I raised to start with. Having read your proposal, it seems changing from time-on-sender to time-on-receiver is a one line change to the patch. What else are you thinking of removing, if anything? Adding an extra parameter adds more obviously and is something I now agree with. > In particular, Simon seems to be basically refusing to do anything about > the complaint that the code fails unless master and standby clocks are > in close sync. I do not believe that this is acceptable, and since he > won't fix it, I guess I'll have to. Syncing two servers in replication is common practice, as has been explained here; I'm still surprised people think otherwise. Measuring the time between two servers is the very purpose of the patch, so the synchronisation is not a design flaw, it is its raison d'etre. There's been a few spleens emptied on that topic, not all of them mine, and certainly no consensus on that. So I'm not refusing to do anything that's been agreed... -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: