Re: Simplify code building the LR conflict messages - Mailing list pgsql-hackers
| From | Amit Kapila |
|---|---|
| Subject | Re: Simplify code building the LR conflict messages |
| Date | |
| Msg-id | CAA4eK1+fRu7aThrJ4az=Ka81bhtYPumd4iZCRHfNh7fNne+M=A@mail.gmail.com Whole thread Raw |
| In response to | RE: Simplify code building the LR conflict messages ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
| Responses |
Re: Simplify code building the LR conflict messages
|
| 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).
>
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?
--
With Regards,
Amit Kapila.
pgsql-hackers by date: