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

On Fri, Jan 9, 2026 at 7:07 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Amit,
>
> > > > Fair enough. Also, with the current approach, we don't need to repeat
> > > > the same LOG message (
> > > > conflict (multiple_unique_conflicts) detected on relation
> > > > "public.conf_tab") again and again even though we do similar things at
> > > > other places[1] (the STATEMENT is repeated). If we have to follow your
> > > > advice then I can think of following formats:
> > ...
> >
> > As shown upthread, in existing places where we display the entire row,
> > we don't use columns, so doesn't see why we need to be different here.
> > I think but we can display for RI columns.
>
> Thanks for the suggestion. I've created the first draft based on the comment.
>
> While considering and implementing, I found that worker sometimes miss to read
> information for indexes and relations due to the missing permissions. Previous
> style just appended key/row/replica identity information at the bottom thus it
> had less impacts.
> However, it needs some branches if we tried to integrate into complete statements
> to avoid constructing sentences at run-time.
>
> E.g., if we have complete information, the output can be like:
>
> ```
> Key (a) = (1) already exists in unique index "tab_pkey", modified in transaction 777: local row (1, 1).
> ```
>
> But if the worker cannot read the content of the index, the statement should be slightly different like:
>
> ```
> Unique index "tab_pkey" rejects applying due to local row (1, 1), modified in transaction 77.
> ```
>
> How do you feel? This patch may need idea to reduce lines.
>

I haven't looked at the code yet, but some initial thoughts while
looking at the output:

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).

2)
LOG:  conflict update_origin_differs detected on relation "public.tab1"
DETAIL:  Remote row (20, 200) was applied but previously modified by
different origin.
Local row (20, 100) detected by replica identity (i)=(20) is being
updated, but it was previously modified locally in transaction 804 at
2026-01-12 14:20:28.346397+05:30.

Row embedded in the sentence may make it difficult to read when the
count of columns is huge.

Shall we make it similar to what we had earlier:
DETAIL:  Updating the row that was modified locally in transaction
<..> at <..>: local row (..), remote row (..), replica identity
(i)=(..).

Or close to newer version:
DETAIL:  The row is being updated, but was previously modified locally
in transaction <..> at <..>: local row (..), remote row (..), replica
identity (i)=(..).

3)
Comment 2 is valid for 'delete_origin_differs' as well. Both should
have exactly the same format.

4)
LOG:  conflict update_deleted detected on relation "public.tab1"
DETAIL:  Could not find remote row (10, 100) by using replica identity (i)=(10).

The remote-row is embedded here too. Shall it be:
DETAIL: Could not find the row by using replica identity (i) = (10):
remote row (10, 100).

Please note that replica-identity when set to FULl can also be huge,
so both RI and remote-row at the end makes sense.

thanks
Shveta