Re: Clock-skew management in logical replication

2024-09-26 Thread Amit Kapila
On Wed, Sep 25, 2024 at 3:09 PM Hayato Kuroda (Fujitsu) 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

RE: Clock-skew management in logical replication

2024-09-25 Thread Hayato Kuroda (Fujitsu)
Dear hackers, > 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 resear

Re: Clock-skew management in logical replication

2024-09-24 Thread Michael Paquier
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

Re: Clock-skew management in logical replication

2024-09-24 Thread Nisha Moond
On Mon, Sep 23, 2024 at 4:00 PM Nisha Moond wrote: > > On Fri, Sep 20, 2024 at 7:51 PM Tom Lane wrote: > > > > Nisha Moond writes: > > > While considering the implementation of timestamp-based conflict > > > resolution (last_update_wins) in logical replication (see [1]), there > > > was a feedba

Re: Clock-skew management in logical replication

2024-09-23 Thread Nisha Moond
On Fri, Sep 20, 2024 at 7:51 PM Tom Lane wrote: > > Nisha Moond writes: > > While considering the implementation of timestamp-based conflict > > resolution (last_update_wins) in logical replication (see [1]), there > > was a feedback at [2] and the discussion on whether or not to manage > > clock

Re: Clock-skew management in logical replication

2024-09-23 Thread Amit Kapila
On Sun, Sep 22, 2024 at 7:24 PM Joe Conway wrote: > > On 9/21/24 01:31, shihao zhong wrote: > > Nisha Moond writes: > >> Thoughts? Looking forward to hearing others' opinions! > > > > Had a productive conversation with Amit Kaplia today about time skew > > in distributed systems, and wanted to sh

Re: Clock-skew management in logical replication

2024-09-22 Thread shihao zhong
> > > Long-term, we should consider integrating with a distributed time > > service like AWS Time Sync Service. This ensures high accuracy and > > scalability for demanding applications. > > > I think the pluggable access method should make > this possible, no? > I am sorry that I did not explai

Re: Clock-skew management in logical replication

2024-09-22 Thread Joe Conway
On 9/21/24 01:31, shihao zhong wrote: Nisha Moond writes: Thoughts? Looking forward to hearing others' opinions! Had a productive conversation with Amit Kaplia today about time skew in distributed systems, and wanted to share some thoughts. Essentially, we're grappling with the classic distri

Re: Clock-skew management in logical replication

2024-09-20 Thread shihao zhong
Nisha Moond writes: > Thoughts? Looking forward to hearing others' opinions! Had a productive conversation with Amit Kaplia today about time skew in distributed systems, and wanted to share some thoughts. Essentially, we're grappling with the classic distributed snapshot problem. In a multi-activ

Re: Clock-skew management in logical replication

2024-09-20 Thread Tom Lane
Nisha Moond writes: > While considering the implementation of timestamp-based conflict > resolution (last_update_wins) in logical replication (see [1]), there > was a feedback at [2] and the discussion on whether or not to manage > clock-skew at database level. FWIW, I cannot see why we would do