Re: Conflict detection for update_deleted in logical replication

On Thu, Jul 3, 2025 at 10:26 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Wed, Jul 2, 2025 at 12:58 PM Zhijie Hou (Fujitsu)
> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> >
>
> > During local testing, I discovered a bug caused by my oversight in assigning
> > the new xmin to slot.effective, which resulted in dead tuples remaining
> > non-removable until restart. I apologize for the error and have provided
> > corrected patches. Kindly use the latest patch set for performance testing.
>
> You changes related to write barrier LGTM, however I have question
> regarding below change, IIUC, in logical replication
> MyReplicationSlot->effective_xmin should be the xmin value which has
> been flushed to the disk, but here we are just setting "data.xmin =
> new_xmin;" and marking the slot dirty so I believe its not been yet
> flushed to the disk right?
>

Yes, because this is a physical slot and we need to follow
PhysicalConfirmReceivedLocation()/PhysicalReplicationSlotNewXmin().
The patch has kept a comment in advance_conflict_slot_xmin() as to why
it is okay not to flush the slot immediately.

--
With Regards,
Amit Kapila.