From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
---|---|
To: | Ajin Cherian <itsajin(at)gmail(dot)com> |
Cc: | 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-08-06 03:17:49 |
Message-ID: | CAJpy0uCyZOD68bGsf1Gwe4Wj0u5z3qASP1VLE5KPoBjPuQUzTw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 6, 2025 at 7:35 AM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> On Tue, Aug 5, 2025 at 4:22 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Tue, Aug 5, 2025 at 9:28 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > On Mon, Aug 4, 2025 at 3:41 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > >
> > > > On Mon, Aug 4, 2025 at 12:19 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > If we want to avoid continuously syncing newly added slots in later
> > > cycles and instead focus only on the ones that failed to sync during
> > > the first attempt, one approach is to maintain a list of failed slots
> > > from the initial cycle and only retry those in subsequent attempts.
> > > But this will add complexity to the implementation.
> > >
> >
> > There will be some additional code for this but overall it improves
> > the code in the lower level functions. We may want to use the existing
> > remote_slot list for this purpose.
> >
> > The current proposed change in low-level functions appears to be
> > difficult to maintain, especially the change proposed in
> > update_and_persist_local_synced_slot(). If we can find a better way to
> > achieve the same then we can consider the current approach as well.
> >
>
> Next patch, I'll work on addressing this comment. I'll need to
> restructure the code to make this happen.
>
Okay, thanks Ajin. I will resume review after this comment is
addressed as I am assuming that the new logic will get rid of most of
the current wait logic and thus it makes sense to review it after it
is addressed.
thanks
Shveta
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-08-06 03:26:43 | Re: More protocol.h replacements this time into walsender.c |
Previous Message | Nathan Bossart | 2025-08-06 02:20:09 | Re: fix ancient typo in transformRelOptions() |