On Fri, Apr 10, 2026 at 8:28 AM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Sunday, March 22, 2026 1:47 AM Amit Kapila <[email protected]> wrote: > > > > * > > @@ -2174,7 +2193,10 @@ > > LogicalSlotAdvanceAndCheckSnapState(XLogRecPtr moveto, > > > > if (XLogRecPtrIsValid(ctx->reader->EndRecPtr)) > > { > > - LogicalConfirmReceivedLocation(moveto); > > + bool slot_updated = LogicalConfirmReceivedLocation(moveto); > > + > > + if (updated_xmin_or_lsn) > > + *updated_xmin_or_lsn = slot_updated; > > > > BTW, LogicalSlotAdvanceAndCheckSnapState() could also advance slot while > > processing running_xact record, so not sure we can rely only on the explicit > > call LogicalConfirmReceivedLocation() above to ascertain the same. > > Perhaps we could simply compare the slot's old and new LSN/xmin to determine > whether updated_xmin_or_lsn needs to be set. This would avoid the need to hook > into each individual update path at the lower level. Attaching a patch for > reference. >
Yes, this sounds like a good idea, I will review it further. > > > > Sorry, I couldn't get the chance to look at the patches proposed by Hou-san > > to > > fix this issue but I'll look at it after the feature freeze. > > The other patches attempt to advance restart_lsn in more cases by modifying > the > logical decoding logic. However, those scenarios are relatively rare and may > not > produce significant improvement outside the slot synchronization context. So, > I > think modifying the slot sync worker to correctly increase the polling > interval instead > is also a good starting point. > Even in slot synchronization, this is a very rare case where the slot on primary is not continuously being advanced as normally we do via walsender, otherwise, we wouldn't have seen LOGs at this frequency. -- With Regards, Amit Kapila.
