Re: Improve pg_sync_replication_slots() to wait for primary to advance
От | Amit Kapila |
---|---|
Тема | Re: Improve pg_sync_replication_slots() to wait for primary to advance |
Дата | |
Msg-id | CAA4eK1JrpRpGKrJ4nehRjm=TgBAu4c7G-rebc_i6zam2TkNJtQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve pg_sync_replication_slots() to wait for primary to advance (Ashutosh Sharma <ashu.coek88@gmail.com>) |
Ответы |
Re: Improve pg_sync_replication_slots() to wait for primary to advance
|
Список | pgsql-hackers |
On Fri, Sep 5, 2025 at 11:39 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > > On Wed, Sep 3, 2025 at 3:20 PM Ajin Cherian <itsajin@gmail.com> wrote: > > > > On Wed, Sep 3, 2025 at 6:47 PM shveta malik <shveta.malik@gmail.com> wrote: > > > > > > On Wed, Sep 3, 2025 at 11:58 AM Ajin Cherian <itsajin@gmail.com> wrote: > > > > > > > > Attaching v10 with the above changes. > > > > > > > > > > The patch does not apply on HEAD. Can you please rebase? > > > > Rebased and made a small change as well to use TopMemoryContext rather > > than create a new context for slot_list. > > > > 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. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: