Re: Conflict detection for update_deleted in logical replication

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?

+advance_conflict_slot_xmin(TransactionId new_xmin)
+{
+ Assert(MyReplicationSlot);
+ Assert(TransactionIdIsValid(new_xmin));
+ Assert(TransactionIdPrecedesOrEquals(MyReplicationSlot->data.xmin, new_xmin));
+
+ /* Return if the xmin value of the slot cannot be advanced */
+ if (TransactionIdEquals(MyReplicationSlot->data.xmin, new_xmin))
+ return;
+
+ SpinLockAcquire(&MyReplicationSlot->mutex);
+ MyReplicationSlot->effective_xmin = new_xmin;
+ MyReplicationSlot->data.xmin = new_xmin;
+ SpinLockRelease(&MyReplicationSlot->mutex);
+
+ elog(DEBUG1, "updated xmin: %u", MyReplicationSlot->data.xmin);
+
+ ReplicationSlotMarkDirty();
+ ReplicationSlotsComputeRequiredXmin(false);
..
}

--
Regards,
Dilip Kumar
Google