Re: Excessive number of replication slots for 12->14 logical replication
От | Amit Kapila |
---|---|
Тема | Re: Excessive number of replication slots for 12->14 logical replication |
Дата | |
Msg-id | CAA4eK1JptEFUvxSFq=cQ=C703ENHuvvFoAA1a8oajRbX6o=GwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Excessive number of replication slots for 12->14 logical replication (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
On Sat, Jul 16, 2022 at 3:44 AM Andres Freund <andres@anarazel.de> wrote: > > On 2022-07-15 13:55:32 +0900, Kyotaro Horiguchi wrote: > > Yeah, the limitation by max_sync_workers_per_subscription is performed > > on subscriber, but replication slot drops happen not on the > > subscriber, but at the termination of corresponding walsender process > > on publisher. We do drop the replication slots on subscribers since commit ce0fdbfe97 once the initial sync is complete. > > So, there's a lag between the finish of subscription > > worker and the corresponding slot's drop. Thus, a new sync worker can > > be created while the walsenders corresponding to some already finished > > sync workers is still going to finish. > > Why are we relying on the slots being dropped at the end of connection? That > doesn't seem like a good idea to me. Can't we just do that explicitly? > We do that explicitly once the initial sync in finished. -- With Regards, Amit Kapila.
В списке pgsql-bugs по дате отправления: