On Thu, Jul 3, 2025 at 10:26 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Wed, Jul 2, 2025 at 12:58 PM Zhijie Hou (Fujitsu) > <houzj.f...@fujitsu.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.
