RE: Simplify code building the LR conflict messages
| От | Hayato Kuroda (Fujitsu) |
|---|---|
| Тема | RE: Simplify code building the LR conflict messages |
| Дата | |
| Msg-id | TY7PR01MB14554780D7CA33DA92CA6E53AF584A@TY7PR01MB14554.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: Simplify code building the LR conflict messages (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Simplify code building the LR conflict messages
|
| Список | pgsql-hackers |
Dear Amit, Sawada-san, > 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: ... Basically they look good to me, but I prefer to clarify the column name for each tuples at least once per one output. Like: ``` DETAIL: Key (a)=(2) already ... local row (a, b, c) = (2, 2, 2), remote row [(a, b, c) = ](2, 3, 4). ``` Admin can easily follow what is the exact reason why it happened. Also, the ordering of column can be different between instances, and it may cause misunderstanding. Currently they would be re-ordered by the subscriber-side ones, but reader may understand by the publisher-side ones. Best regards, Hayato Kuroda FUJITSU LIMITED
В списке pgsql-hackers по дате отправления: