Re: Conflict Detection and Resolution
От | Dilip Kumar |
---|---|
Тема | Re: Conflict Detection and Resolution |
Дата | |
Msg-id | CAFiTN-s+azdtka0wZ-azFyu1pb2d4KS93byJ0SYnzJBrGf4=Jw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Conflict Detection and Resolution (Ajin Cherian <itsajin@gmail.com>) |
Ответы |
Re: Conflict Detection and Resolution
|
Список | pgsql-hackers |
On Fri, Jul 26, 2024 at 9:50 AM Ajin Cherian <itsajin@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? 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. I am doing code level review as well and will share my comments soon on 0003 and 0004 -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: