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  (Robert Haas <robertmhaas@gmail.com>)
Re: Keepalive for max_standby_delay  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Keepalive for max_standby_delay
Следующее
От: Chris Browne
Дата:
Сообщение: Re: Exposing the Xact commit order to the user