RE: Simplify code building the LR conflict messages

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, 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>, 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>
Subject: RE: Simplify code building the LR conflict messages
Date: 2026-01-09 13:37:16
Message-ID: TY7PR01MB14554864222E9C015959D9EC8F582A@TY7PR01MB14554.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
0001-Fix-errdetail-for-logical-replication-conflict.patch application/octet-stream 43.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-01-09 13:42:53 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Mihail Nikalayeu 2026-01-09 13:26:41 Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY