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

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: depesz@depesz.com, pgsql-bugs@lists.postgresql.org
Date: 2022-07-15T22:14:07Z
Lists: pgsql-bugs
Hi,

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. 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
still need the on-connection-close cleanup to deal with network failures etc,
but that doesn't mean we can do something else in the happy path.

Greetings,

Andres Freund



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.