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 по дате отправления: