Re: Simplify code building the LR conflict messages - Mailing list pgsql-hackers

On Wed, Jan 14, 2026 at 5:01 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Amit, Shveta,
>
> > >
> > > 1)
> > > DETAIL:  Could not apply remote row (20, 10).
> > > DETAIL:  Could not apply remote row (40, 200) by using replica
> > > identity (i)=(20).
> > >
> > > We generally "apply" in terms of insert, update, delete etc and not
> > > rows. Do you think we shall have:
> > > 'Could not apply remote change (20, 10)..'
> > >
> > > The most informative will be to say below, but since operation-type is
> > > already mentioned in Context, mentioning it here might not be needed.
> > > So we can say 'remote change'.
> > >
> > > DETAIL: Could not apply remote INSERT for row (30, 10).
> > > DETAIL: Could not apply remote UPDATE for row (40, 200) using replica
> > > identity (i)=(20).
> > >
> >
> > IIRC, the operation is already displayed in the context message. Here,
> > we can say: DETAIL: Could not apply remote change using replica
> > identity (i)=(20): remote row (40, 200).
>
> Thanks for suggestions. I updated accordingly. Also, I found that local slot won't
> be available in case of update_deleted, thus I removed from the code.
> Current concern is that {update|delete}_origin_differ still construct the message
> because there are three printable info. Can you suggest if you know better approaches?
>
>
> In below I want to show some examples.
>
> Case 1: multiple_unique_conflicts with UPDATE
> HEAD:
> DETAIL:  Key already exists in unique index "foo_pkey", modified locally in transaction 789 at ...
>         Key (a)=(6); existing local row (6, 6, 6); remote row (6, 7, 8); replica identity (a)=(5).
>         Key already exists in unique index "foo_b_key", modified locally in transaction 789 at ...
>         Key (b)=(7); existing local row (7, 7, 7); remote row (6, 7, 8); replica identity (a)=(5).
>         Key already exists in unique index "foo_c_key", modified locally in transaction 789 at ...
>         Key (c)=(8); existing local row (8, 8, 8); remote row (6, 7, 8); replica identity (a)=(5).
>
> V1:
> DETAIL:  Could not apply remote row (6, 7, 8) by using replica identity (a)=(5).
>         Key (a)=(6) already exists in unique index "foo_pkey", modified locally in transaction 790 at ...: local row
(6,6, 6). 
>         Key (b)=(7) already exists in unique index "foo_b_key", modified locally in transaction 790 at ...: local row
(7,7, 7). 
>         Key (c)=(8) already exists in unique index "foo_c_key", modified locally in transaction 790 at ...: local row
(8,8, 8). 
>
> V2:
> DETAIL:  Could not apply remote change by using replica identity (a)=(5): remote row (6, 7, 8).
>         Key (a)=(6) already exists in unique index "foo_pkey", modified locally in transaction 788 at ...: local row
(6,6, 6). 
>         Key (b)=(7) already exists in unique index "foo_b_key", modified locally in transaction 788 at ...: local row
(7,7, 7). 
>         Key (c)=(8) already exists in unique index "foo_c_key", modified locally in transaction 788 at ...: local row
(8,8, 8). 
>
> Case 2: update_origin_differs
> HEAD:
> DETAIL:  Updating the row that was modified locally in transaction 790 at ...
>         Existing local row (5, 5, 5); remote row (6, 7, 8); replica identity (a)=(5).
>
> V1:
> DETAIL:  Remote row (6, 7, 8) was applied but previously modified by different origin.
>         Local row (5, 5, 5) detected by replica identity (a)=(5) is being updated, but it was previously modified
locallyin transaction 790 at .... 
>
> V2:
> DETAIL:  Updating the row that was modified locally in transaction 790 at ...: local row (5, 5, 5), remote row (6, 7,
8),replica identity (a)=(5). 
>
> Case 3: delete_origin_differs with huge column
> HEAD:
> DETAIL:  Deleting the row that was modified locally in transaction 795 at ...
>         Existing local row (1, testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...); replica identity
(id)=(1).
>
> V1:
> DETAIL:  Local row (1, testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...) detected by replica
identity(id)=(1) is being deleted, but it was previously modified locally in transaction 797 at .... 
>
> V2:
> DETAIL:  Deleting the row that was modified locally in transaction 807 at ...: local row (1,
testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest...),replica identity (id)=(1). 
>
> Case 4: update_deleted
> HEAD:
> DETAIL:  The row to be updated was deleted locally in transaction 789 at ...
>         Remote row (6, 7, 8); replica identity (a)=(5).
>
> V1:
> DETAIL:  Could not find remote row (6, 7, 8) by using replica identity (a)=(5).
>         Local row was previously deleted locally in transaction 795 at ....
>
> V2:
> DETAIL:  Could not find the row by using replica identity (a)=(5): remote row (6, 7, 8).
>         The row to be updated was deleted locally in transaction 789 at ....
>

To me v2 of each looks better as all the rows and RI (which could be
huge) are at the end. Let's see what others have to say here.

For delete_origin_differs and update_origin_differs, I considered
using the phrase “by using replica identity,” as we do in other
messages. But it doesn’t read well in this context. For example, the
sentence below sounds slightly awkward:

Updating/Deleting the row that was modified locally in transaction <…>
at <…> using replica identity (a) = (5): local row (5, 5, 5), remote
row (6, 7, 8).

More importantly, this wording may be confusing, as it’s unclear
whether “using replica identity” refers to the current operation or to
the earlier operation that modified the row and caused the origin to
differ. Therefore, I’ll stick with the V2 wording suggested above.

thanks
Shveta