On Tue, Oct 7, 2025 at 4:49 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, Oct 7, 2025 at 3:47 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Tue, Oct 7, 2025 at 3:24 PM Ajin Cherian <itsajin@gmail.com> wrote:
> > >
> > > Hello Hackers,
> > >
> > > In an offline discussion, I was considering adding a TAP test for this
> > > patch. However, testing the pg_sync_replication_slots() API’s wait
> > > logic requires a delay of at least 2 seconds, since that’s the
> > > interval the API sleeps before retrying. I’m not sure it’s acceptable
> > > to add a TAP test that increases runtime by 2 seconds.
> > > I’m also wondering if 2 seconds is too long for the API to wait?
> > > Should we reduce it to something like 200 ms instead? I’d appreciate
> > > your feedback.
> > >
> >
> > I feel a shorter nap will be good since it is an API and should finish
> > fast. But too short a nap may result in too many primary pings
> > specially when primary-slots are not advancing. But that case should
> > be a rare one. Shall we have a nap of say 500ms? It is neither too
> > short nor too long. Thoughts?
>
> Shorter nap times mean higher possibility of wasted CPU cycles - that
> should be avoided. Doing that for a test's sake seems wrong. Is there
> a way that the naptime can controlled by external factors such as
> likelihood of an advanced slot (just firing bullets in the dark) or is
> the naptime controllable by user interface like GUC? The test can use
> those interfaces.
>
Yes, we can control naptime based on the fact whether any slots are
being advanced on primary. This is how a slotsync worker does. It
keeps on doubling the naptime if there is no activity on primary
starting from 200ms till max of 30 sec. As soon as activity happens,
naptime is reduced to 200ms again.
thanks
Shveta
