Thread: Runaway Initial Table Syncs in Logical Replication?

On Friday, August 4, 2023 3:24 AM Don Seiler <don@seiler.us>  wrote:

Hi,

Thanks for reporting.

> Logical Rep question. Publisher is PG12 on Ubuntu 18.04, subscriber is PG15 on
> Ubuntu 22.04.

Just to confirm, which subversion of PG15 are you using on the subscriber side ?
Is it 15.3 ? I am confirming because I recall we fixed similar bug before in commit [1].

> 
> I bumped up some values to see how initial load times change. I set
> max_logical_replication_workers to 20 and max_sync_workers_per_subscription to
> 4. I’m using 3 subscriptions, 2 of the subscriptions have 3 tables each, the
> other has a lot more, say 100 for the sake of example.What we noticed was that
> the subscriber basically maxed out the wal senders and replication slots on the
> publisher side, even when the publisher settings were bumped up to 50 each. 3
> replication slots were for the 3 subs and the rest (47) were sync workers. Was
> creating a sync worker for each table right away, or at least trying to? The
> subscriber side was still complaining that it couldn’t create more replication
> slots on the publisher. 

Are there any ERRORs(including erros other than the slots number) in the log of publisher and subscriber.
It would be helpful to see the log in case there are some other ERRORs that could cause problem.

> 
> I was expecting to see max_sync_workers_per_subscription (4) x # of subs (3) =
> 12 sync workers in action so this was a big surprise. Is this expected
> behavior?


Best Regards,
Hou zj

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f6c5edb8abcac04eb3eac6da356e59d399b2bcef