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
0001-Fix-errdetail-for-logical-replication-conflict.patch
Description: 0001-Fix-errdetail-for-logical-replication-conflict.patch
