From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve pg_sync_replication_slots() to wait for primary to advance |
Date: | 2025-10-09 08:43:48 |
Message-ID: | CAA4eK1LMUwzoq=pwr_O=9nP4cOe5+q=QznWLLdkPCpq8kaB7bQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 7, 2025 at 5:13 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Tue, Oct 7, 2025 at 4:49 PM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> >
> > 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.
>
Is there a reason why we don't want to use the same naptime strategy
for API and worker?
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2025-10-09 08:45:24 | Re: Enhance Makefiles to rebuild objects on map file changes |
Previous Message | Rahila Syed | 2025-10-09 08:43:25 | Re: Enhancing Memory Context Statistics Reporting |