RE: Simplify code building the LR conflict messages
| От | Hayato Kuroda (Fujitsu) |
|---|---|
| Тема | RE: Simplify code building the LR conflict messages |
| Дата | |
| Msg-id | TY7PR01MB14554864222E9C015959D9EC8F582A@TY7PR01MB14554.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: Simplify code building the LR conflict messages (Amit Kapila <amit.kapila16@gmail.com>) |
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: