Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAA4eK1JT+KYGeuj8PXjP6OB_0L2aeMGL1PYz_MrRe2xyBa+EJw@mail.gmail.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Per-thread leak in ECPG's memory.c
Re: Per-thread leak in ECPG's memory.c
List pgsql-hackers
On Sun, Aug 23, 2026 at 1:45 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Friday, August 21, 2026 6:46 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Thu, Aug 20, 2026 at 8:15 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
> > wrote:
> > >
> > > One more thing 0001 could potentially do is replace the existing
> > > references to stream_xid with ApplyRemoteCtx.remote_xid. It's not done
> > > in the patch yet, but can be if we reach consensus.
> > >
> >
> > We can do this without breaking anything but this doesn't sound
> > fundamentally correct. Because stream_xid is valid only inside a STREAM
> > START/STOP block whereas remote_ctx.remote_xid is valid for the whole
> > transaction(including the COMMIT/PREPARE/ABORT phase), and is used for
> > non-streamed transactions. So remote_xid is deliberately valid at moments
> > when stream_xid is deliberately Invalid. So, I suggest leaving this as it is.
> >
> > I have made few changes in 0001 refactor patch (a) Change the mix use of
> > errarg and remote_ctx in apply_error_callback as that looks confusing, instead
> > used a shorter variable name ctx so that some of the lines where it is used
> > doesn't overflow, (b) changed comments at various places. Let me know what
> > you think of attached.
>
> Thanks for updating the patch, it looks good to me.
>

Pushed.

--
With Regards,
Amit Kapila.



Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: remove_useless_joins vs. bug #19560
Next
From: Rafia Sabih
Date:
Subject: Re: Bypassing cursors in postgres_fdw to enable parallel plans