Re: Conflict detection and logging in logical replication - Mailing list pgsql-hackers

From shveta malik
Subject Re: Conflict detection and logging in logical replication
Date
Msg-id CAJpy0uA7_kW7wP=iV8mL9a9YJCWt8G6R-7-+2D6HJGW3JoFZ+A@mail.gmail.com
Whole thread Raw
In response to Re: Conflict detection and logging in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Conflict detection and logging in logical replication
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [PATCH] Add CANONICAL option to xmlserialize
Next
From: Dean Rasheed
Date:
Subject: Re: Optimize mul_var() for var1ndigits >= 8