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

On Fri, Jan 16, 2026 at 9:16 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jan 14, 2026 at 5:01 PM Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> >
> > 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). 
> >
>
> V2 looks better as in V1, if the length of the remote row is large
> then it would be inconvenient to read.
>
> > 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). 
> >
>
> In V2 for case-2 and case-3, it seems you only removed 'Existing'
> before the local row, is that correct?
>
> > 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 ....
> >
>
> V2 looks better because of the same reason as for case-1.
>
> You haven't shared the details for update/delete_missing and
> insert/update_exists. Is it because they haven't changed or something
> else?
>

One more point:
HEAD: conflict detected on relation "public.tab_full_pk":
conflict=update_missing
PATCH: conflict update_missing detected on relation "public.tab_full_pk"

I am not very sure whether all users like the change of moving
conflict_type to earlier in the message string even though it appears
better. I think it will be easier for scripts to grep what we have in
HEAD. Can we at least move it to a second patch so that we can discuss
it separately once the DETAIL messages are fixed.

BTW, the patch should update the docs [1] to reflect the changes.

[1] - https://www.postgresql.org/docs/devel/logical-replication-conflicts.html

--
With Regards,
Amit Kapila.