Re: Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Now, measuring time skew is potentially a useful thing to do, if we
> believe that this will actually give us an accurate measurement of
> what the time skew is, because there are a whole series of things that
> people want to do which involve subtracting a slave timestamp from a
> master timestamp. Tom has persistently rebuffed all such proposals on
> the grounds that there might be time skew, so in theory we could make
> those things possible by having a way to measure time skew, which this
> does. Here's what we do: given a slave timestamp, add the estimated
> time skew to find an equivalent master timestamp, and then subtract.
> Using a method of this type would allow us to compute a *real* apply
> delay. Woohoo! Unfortunately, if time synchronization IS in use,
> then the system clocks are probably already synchronized three to six
> orders of magnitude more precisely than what this method can measure,
> so the effect of using GetReplicationTransferLatency() to adjust slave
> timestamps will be to massively reduce the accuracy of such
> calculations. However, I've thus far been unable to convince anyone
> that this is a bad idea, so maybe this is where we're gonna end up.

Hmm ... first question is do we actually care whether the clocks are
synced to the millisecond level, ie what is it you'd do differently
if you know that the master and slave clocks are synced more closely
than you can measure at the protocol level.

But if there is a reason to care, perhaps we could have a setting that
says "we're using NTP, so trust the clocks to be synced"? What I object
to is assuming that without any evidence, or being unable to operate
correctly in an environment where it's not true.

regards, tom lane