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

From: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, shveta malik <shveta(dot)malik(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-09-08 04:26:49
Message-ID: CAE9k0PkBdTy5SmFCGS7k=h5txefGqkT=Vodexgo1ERrrzoMbKA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 8, 2025 at 9:51 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Sat, Sep 6, 2025 at 9:14 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Sep 5, 2025 at 11:39 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> > > If the remote slot is inactive since long and lagging behind the
> > > standby, this function (pg_sync_replication_slots) could end up
> > > waiting indefinitely. While it can certainly be cancelled manually,
> > > that behavior might not be ideal for everyone. That’s my
> > > understanding; please let me know if you see it differently.
> > >
> >
> > Such a case can be addressed by having additional timeout parameters.
> > We can do that as an additional patch if the use case is important
> > enough to address.
> >
>
> Or we could rely on statement_timeout or the user cancelling the query
> explicitly.
>

Sure. thanks Amit and Ashutosh.

--
With Regards,
Ashutosh Sharma.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2025-09-08 04:31:16 Re: Improve pg_sync_replication_slots() to wait for primary to advance
Previous Message Ashutosh Sharma 2025-09-08 04:22:25 Re: How can end users know the cause of LR slot sync delays?