On Fri, Oct 18, 2024 at 4:30 PM Zhijie Hou (Fujitsu) <houzj.f...@fujitsu.com> wrote: > > On Wednesday, October 9, 2024 2:34 PM shveta malik <shveta.ma...@gmail.com> > wrote: > > > > On Wed, Oct 9, 2024 at 8:58 AM shveta malik <shveta.ma...@gmail.com> > > wrote: > > > > > > On Tue, Oct 8, 2024 at 3:12 PM Nisha Moond > > <nisha.moond...@gmail.com> wrote: > > > > > > > > > > > Please find few comments on v14-patch004: > > > > patch004: > > 1) > > GetConflictResolver currently errors out when the resolver is > > last_update_wins > > and track_commit_timestamp is disabled. It means every conflict resolution > > with this resolver will keep on erroring out. I am not sure if we should > > emit > > ERROR here. We do emit ERROR when someone tries to configure > > last_update_wins but track_commit_timestamp is disabled. I think that should > > suffice. The one in GetConflictResolver can be converted to WARNING max. > > > > What could be the side-effect if we do not emit error here? In such a case, > > the > > local timestamp will be 0 and remote change will always win. > > Is that right? If so, then if needed, we can emit a warning saying > > something like: > > 'track_commit_timestamp is disabled and thus remote change is applied > > always.' > > > > Thoughts? > > I think simply reporting a warning and applying remote changes without further > action could lead to data inconsistencies between nodes. Considering the > potential challenges and time required to recover from these inconsistencies, > I > prefer to keep reporting errors, in which case users have an opportunity to > resolve the issue by enabling track_commit_timestamp. >
Okay, makes sense. We should raise ERROR then. thanks Shveta
