Re: Time-Delayed Standbys

On 9 Dec 2013 12:16, "Craig Ringer" <craig(at)2ndquadrant(dot)com> wrote:

> The only way to "deal with" clock drift that isn't fragile in the face
> of variable latency, etc, is to basically re-implement (S)NTP in order
> to find out what the clock difference with the remote is.

There's actually an entirely different way to "deal" with clock drift: test
"master time" and "slave time" as two different incomparable spaces.
Similar to how you would treat measurements in different units.

If you do that then you can measure and manage the delay in the slave
between receiving and applying a record and also measure the amount of
master server time which can be pending. These measurements don't depend at
all on time sync between servers.

The specified feature depends explicitly on the conversion between master
and slave time spaces so it's inevitable that sync would be an issue. It
might be nice to print a warning on connection if the time is far out of
sync or periodically check. But I don't think reimplementing NTP is a good
idea.