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

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

To: shveta malik <shveta.malik@gmail.com>

Cc: Ajin Cherian <itsajin@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>

Date: 2025-10-07T11:19:26Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Enhance slot synchronization API to respect promotion signal.
- 4bed04d39566 17.10 landed
- 94efd308bcec 18.4 landed
- 1362bc33e025 19 (unreleased) landed
Fix inconsistent elevel in pg_sync_replication_slots() retry logic.
- f1ddaa15357f 19 (unreleased) landed
Refactor slot synchronization logic in slotsync.c.
- 788ec96d591d 19 (unreleased) landed
Fix intermittent BF failure in 040_standby_failover_slots_sync.
- b47c50e5667b 19 (unreleased) landed
Add retry logic to pg_sync_replication_slots().
- 0d2d4a0ec3ec 19 (unreleased) landed
Fix LOCK_TIMEOUT handling in slotsync worker.
- 04396eacd3fa 19 (unreleased) cited
Add slotsync skip statistics.
- 76b78721ca49 19 (unreleased) cited

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.

-- 
Best Wishes,
Ashutosh Bapat