On Fri, Apr 10, 2026 at 8:28 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Sunday, March 22, 2026 1:47 AM Amit Kapila <amit.kapila16@gmail.com> 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.
