Re: Clock-skew management in logical replication

On Wed, Sep 25, 2024 at 3:09 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> > Though this provides a way for users to control values required for
> > conflict resolution, I prefer a simple approach at least for the first
> > version which is to document that users should ensure time
> > synchronization via NTP. Even Oracle mentions the same in their docs
>
> I researched some cloud services and found that the time-sync services on the
> cloud are integrated with the NTP or PTP direct connection. This means that there
> are no specific APIs to synchronize the machine clock. Based on that,
> I also agree with the simple approach (just document). I feel the synchronization
> can be regarded as the low-layer task and can rely on the OS.
>
> The below part shows the status of cloud vendors and Oracle.
>
> ## AWS case
>
> AWS provides a "Time Sync Service" [1] that can be used via NTP. The source server
> is at 169.254.169.123; users can modify the configuration file to refer to it shown below.
>
> ```
> server 169.254.169.123 prefer iburst
> ```
>
> Or users can even directly connect to the local and accurate hardware clock.
>
> ## GCP case
>
> GCP compute engines must use an NTP server on the GCP cloud [2], located at
> metadata.google.internal, or other public NTP servers. The configuration will
> look like this:
>
> ```
> server metadata.google.internal iburst
> ```
>

If NTP already provides a way to configure other time-sync services as
shown by you then I don't think we need to do more at this stage
except to document it with the conflict resolution patch. In the
future, we may want to provide an additional column in the table with
a special meaning that can help in conflict resolution.

--
With Regards,
Amit Kapila.