| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: Simplify code building the LR conflict messages |
| Date: | 2026-01-07 10:07:11 |
| Message-ID: | TY7PR01MB14554780D7CA33DA92CA6E53AF584A@TY7PR01MB14554.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Chen | 2026-01-07 10:22:01 | Re: Proposal: Add a UNIQUE NOT ENFORCED constraint |
| Previous Message | dinesh salve | 2026-01-07 10:00:25 | Re: explain plans for foreign servers |