On Tue, Jul 30, 2024 at 4:56 PM shveta malik <shveta.ma...@gmail.com> wrote: > > On Tue, Jul 30, 2024 at 4:04 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > On Fri, Jul 26, 2024 at 9:50 AM Ajin Cherian <itsa...@gmail.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 for the clarification. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
