Re: Conflict detection and logging in logical replication
От | shveta malik |
---|---|
Тема | Re: Conflict detection and logging in logical replication |
Дата | |
Msg-id | CAJpy0uA7_kW7wP=iV8mL9a9YJCWt8G6R-7-+2D6HJGW3JoFZ+A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Conflict detection and logging in logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
RE: Conflict detection and logging in logical replication
|
Список | pgsql-hackers |
On Mon, Aug 26, 2024 at 3:22 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Aug 22, 2024 at 2:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, Aug 22, 2024 at 1:33 PM Peter Smith <smithpb2250@gmail.com> wrote: > > > > > > Do you think the documentation for the 'column_value' parameter of the > > > conflict logging should say that the displayed value might be > > > truncated? > > > > > > > I updated the patch to mention this and pushed it. > > > > Peter Smith mentioned to me off-list that the names of conflict types > 'update_differ' and 'delete_differ' are not intuitive as compared to > all other conflict types like insert_exists, update_missing, etc. The > other alternative that comes to mind for those conflicts is to name > them as 'update_origin_differ'/''delete_origin_differ'. +1 on 'update_origin_differ'/''delete_origin_differ'. Gives more clarity. > The description in docs for 'update_differ' is as follows: Updating a > row that was previously modified by another origin. Note that this > conflict can only be detected when track_commit_timestamp is enabled > on the subscriber. Currently, the update is always applied regardless > of the origin of the local row. > > Does anyone else have any thoughts on the naming of these conflicts? > > -- > With Regards, > Amit Kapila.
В списке pgsql-hackers по дате отправления: