Re: Conflict Detection and Resolution

On Tue, Jul 30, 2024 at 4:04 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Fri, Jul 26, 2024 at 9:50 AM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> Comment in 0002,
>
> 1) I do not see any test case that set a proper conflict type and
> conflict resolver, all tests either give incorrect conflict
> type/conflict resolver or the conflict resolver is ignored
>
> 0003
> 2) I was trying to think about this patch, so suppose we consider this
> case conflict_type-> update_differ resolver->remote_apply, my
> question is to confirm whether my understanding is correct. So if
> this is set and we have 2 nodes and set up a 2-way logical
> replication, and if a conflict occurs node-1 will take the changes of
> node-2 and node-2 will take the changes of node-1?

Yes, that's right.

> Maybe so I think
> to avoid such cases user needs to set the resolver more thoughtfully,
> on node-1 it may be set as "skip" and on node-1 as "remote-apply" so
> in such cases if conflict happens both nodes will have the value from
> node-1. But maybe it would be more difficult to get a consistent
> value if we are setting up a mess replication topology right? Maybe
> there I think a more advanced timestamp-based option would work better
> IMHO.

Yes, that's correct. We can get data divergence with resolvers like
'remote_apply', 'keep_local' etc. If you meant 'mesh' replication
topology, then yes, it is difficult to get consistent value there with
resolvers other than timestamp based. And thus timestamp based
resolvers are needed and should be the default when implemented.

thanks
Shveta