From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Keepalive for max_standby_delay |
Date: | 2010-06-02 18:27:37 |
Message-ID: | 1275503257.21465.2805.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-06-02 18:35:10 | Re: Keepalive for max_standby_delay |
Previous Message | Greg Stark | 2010-06-02 18:23:44 | Re: Keepalive for max_standby_delay |