<p dir="ltr"><br /> On 9 Dec 2013 12:16, "Craig Ringer" <<a
href="mailto:craig@2ndquadrant.com">craig@2ndquadrant.com</a>>wrote:<p dir="ltr">> The only way to "deal with"
clockdrift that isn't fragile in the face<br /> > of variable latency, etc, is to basically re-implement (S)NTP in
order<br/> > to find out what the clock difference with the remote is.<br /><p dir="ltr">There's actually an
entirelydifferent 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.<p dir="ltr">If you do that then you can measure
andmanage the delay in the slave between receiving and applying a record and also measure the amount of master server
timewhich can be pending. These measurements don't depend at all on time sync between servers.<p dir="ltr">The
specifiedfeature depends explicitly on the conversion between master and slave time spaces so it's inevitable that sync
wouldbe 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.
