Horton

Re: Simplify code building the LR conflict messages

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-04T06:28:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve errdetail for logical replication conflict messages.

On Wed, Dec 3, 2025 at 11:34 PM Mihail Nikalayeu
<mihailnikalayeu@gmail.com> wrote:
>
> Hello, everyone!
>
> On Wed, Dec 3, 2025 at 3:41 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> > I think it's odd that conflict resolution depends on log entries.  I
> > think it would be much more valuable if conflict reporting would save
> > the details of the conflict to some kind of conflict logging table.
> > How exactly are we expecting that users would bring the data from the
> > log file to a database row, when they are to be merged?  What happens if
> > there are bytea columns in the table?
>
> Such a proposal exists already at [0].
>

Thanks for providing the information.

> Also, sorry for being noisy and a little-bit offtopic but I think it
> is a good moment to highlight the fact that such messages are also not
> so useful because sometimes they are just clearly incorrect...
> You may find details and reproducers at [1] and [2].
>

Yes, I am aware of those, but IIRC, those are due to the traditional
design choice of using DirtySnapshot during the apply-phase of logical
replication. We need to discuss that separately and come to a
conclusion.

-- 
With Regards,
Amit Kapila.