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

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

In response to

Responses

Browse pgsql-hackers by date

  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()