| From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Ashutosh Sharma <ashu(dot)coek88(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:21:23 |
| Message-ID: | CAExHW5tVvjD8LKoz=evPwgj11pqOYM4xDqnC4UwE-c5f-ZeWAg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Best Wishes,
Ashutosh Bapat
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Sharma | 2025-09-08 04:22:25 | Re: How can end users know the cause of LR slot sync delays? |
| Previous Message | Ashutosh Bapat | 2025-09-08 04:20:04 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |