Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Tue, Oct 7, 2025 at 3:47 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Tue, Oct 7, 2025 at 3:24 PM Ajin Cherian <itsajin(at)gmail(dot)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.

--
Best Wishes,
Ashutosh Bapat