Re: Clock-skew management in logical replication

On Fri, Sep 20, 2024 at 10:21:34AM -0400, Tom Lane wrote:
> FWIW, I cannot see why we would do anything beyond suggesting that
> people run NTP. That's standard anyway on the vast majority of
> machines these days. Why would we add complexity that we have
> to maintain (and document) in order to cater to somebody not doing
> that?

Agreed. I am on the same boat as you are here. I don't think that
the database should be in charge of taking like decisions based on a
clock that may have gone crazy. Precise clocks are a difficult
problem, for sure, but this patch is just providing a workaround for a
problem that should not be linked to the backend engine by default and
I agree that we will feel better if we neither maintain this stuff nor
enter in this territory.

Making that more pluggable, though, has the merit to let out-of-core
folks do what they want, even if we may finish with an community
ecosystem that has more solutions than the number of fingers on one
hand. I've seen multiple ways of solving conflicts across multiple
logical nodes in the past years, some being clock-based, some not,
with more internal strictly-monotonic counting solution to solve any
conflicts.
--
Michael