From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | Ajin Cherian <itsajin(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
Subject: | Re: Improve pg_sync_replication_slots() to wait for primary to advance |
Date: | 2025-09-01 03:30:37 |
Message-ID: | CAJpy0uAcm0b6cTnUK0GcRfYM+6B5Sszoe6rum_eF4uwev+8S7A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 29, 2025 at 4:14 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Fri, Aug 29, 2025 at 2:37 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Fri, Aug 29, 2025 at 2:20 PM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > >
> > > @@ -1276,7 +1331,7 @@ wait_for_slot_activity(bool some_slot_updated)
> > >
> > > The function is too cute to be useful. The code should be part of
> > > ReplSlotSyncWorkerMain() just like other worker's main functions.
> > >
> >
> > I was thinking we can retain wait_for_slot_activity() as this can even
> > be invoked from API flow. See my comment# 2 in [1]
>
> We want the SQL callable function to finish as fast as possible, and
> make all the slots sync ready as fast as possible. So a shorter nap
> time makes sense. We don't want to increase it per iteration. But sync
> worker is a long running worker and can afford to wait longer. In fact
> it should wait longer so as not to load the primary and the standby.
> Given that the naptimes in both cases can not be controlled by the
> same logic, I think it's better not to use the same function.
Okay, makes sense.
thanks
Shveta
From | Date | Subject | |
---|---|---|---|
Next Message | Chao Li | 2025-09-01 03:32:11 | Re: allow benign typedef redefinitions (C11) |
Previous Message | Michael Paquier | 2025-09-01 03:25:45 | Re: Remove traces of long in dynahash.c |