MIME-Version: 1.0
References: 
 <CAHGQGwF6zG9Z8ws1yb3hY1VqV-WT7hR0qyXCn2HdbjvZQKufDw@mail.gmail.com>
 <CAA4eK1KLk+TWyNPJ=z6SzQQXySc-N9Gs3eR-QKfV+MX7vfJWiw@mail.gmail.com>
 <CAHGQGwG1br8SQQnBieyJeRAmnMejEtJrVmurfTPxNouLHSW=jA@mail.gmail.com>
 <CAA4eK1KB6geysORVyOh-dJ+9U57CBC30K2XD3fQ6SKZc0Hsi3Q@mail.gmail.com>
 <TYRPR01MB14195ED854BE834AFDC815E9494592@TYRPR01MB14195.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <TYRPR01MB14195ED854BE834AFDC815E9494592@TYRPR01MB14195.jpnprd01.prod.outlook.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Fri, 10 Apr 2026 09:47:40 +0530
Message-ID: 
 <CAA4eK1Jt2pgVoO-AHrWhUOrwPeYWFEYTJ6wYS5rXNb6HXrWXCA@mail.gmail.com>
Subject: Re: Fix slotsync worker busy loop causing repeated log messages
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Fujii Masao <masao.fujii@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1Jt2pgVoO-AHrWhUOrwPeYWFEYTJ6wYS5rXNb6HXrWXCA%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 10, 2026 at 8:28=E2=80=AFAM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Sunday, March 22, 2026 1:47 AM Amit Kapila <amit.kapila16@gmail.com> w=
rote:
> >
> > *
> > @@ -2174,7 +2193,10 @@
> > LogicalSlotAdvanceAndCheckSnapState(XLogRecPtr moveto,
> >
> >   if (XLogRecPtrIsValid(ctx->reader->EndRecPtr))
> >   {
> > - LogicalConfirmReceivedLocation(moveto);
> > + bool slot_updated =3D LogicalConfirmReceivedLocation(moveto);
> > +
> > + if (updated_xmin_or_lsn)
> > + *updated_xmin_or_lsn =3D slot_updated;
> >
> > BTW, LogicalSlotAdvanceAndCheckSnapState() could also advance slot whil=
e
> > processing running_xact record, so not sure we can rely only on the exp=
licit
> > call LogicalConfirmReceivedLocation() above to ascertain the same.
>
> Perhaps we could simply compare the slot's old and new LSN/xmin to determ=
ine
> 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 fo=
r 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 modifyi=
ng 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 in=
terval 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.

--=20
With Regards,
Amit Kapila.