Re: Excessive number of replication slots for 12->14 logical replication

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Hubert Lubaczewski <depesz@depesz.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-07-18T03:51:21Z
Lists: 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.



Commits

  1. Make the tablesync worker's replication origin drop logic robust.

  2. Drop replication origin slots before tablesync worker exits.

  3. Allow multiple xacts during table sync in logical replication.