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.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
