On Fri, Jan 16, 2026 at 9:16 AM Amit Kapila <[email protected]> wrote: > > On Wed, Jan 14, 2026 at 5:01 PM Hayato Kuroda (Fujitsu) > <[email protected]> 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.
