Re: Simplify code building the LR conflict messages
| От | Amit Kapila |
|---|---|
| Тема | Re: Simplify code building the LR conflict messages |
| Дата | |
| Msg-id | CAA4eK1J3oRCcQNeEwKoR=ZGY9ijrnz8dfFCkLyPykuiX-whN4g@mail.gmail.com обсуждение исходный текст |
| Ответ на | RE: Simplify code building the LR conflict messages ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
| Ответы |
RE: Simplify code building the LR conflict messages
|
| Список | pgsql-hackers |
On Wed, Jan 7, 2026 at 3:37 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > 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. > 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. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: