Re: Simplify code building the LR conflict messages

On Fri, Jan 16, 2026 at 9:16 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Jan 14, 2026 at 5:01 PM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)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 locally in 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.