BUG #19041: Logical replication locks wal processing

The following bug has been logged on the website:

Bug reference: 19041
Logged by: Sergey Belyashov
Email address: sergey(dot)belyashov(at)gmail(dot)com
PostgreSQL version: 17.6
Operating system: Debian bookworm x86_64
Description:

I have few Postgresql servers: A, B, C, D... Each servers has tables: users,
settings and t with partitions t1, t2, t3... Server A publish tables users
and settings, and other servers are subscribed on them using one
subscription (logical replication is used). Other servers publish tables t
and server A subscribed on it (it does not matter, I think). When I create
table s (without indexes) on server A and copy huge about of rows (30M+) all
workers which do replication users,settings tables loads cpu cores by 35-80%
for a long time (5+ hours, I do not wait more). WAL is raising at this time
(37GB+). When I drop subscriptions to these tables from servers B, C... then
WAL is processed very fast. When I keep only one subscription undropped then
WAL is processed (reduced to 2-3 GB) in a hour and only one process eats
35-50% of CPU core time until WAL is not processed. Tables users and
settings are not changed or using (there are not foreign keys in the table
s) during the issued case. So the impact on their publication/subscriptions
is unexpected.

server_a# create table users (user_id integer, name text);
server_a# create table settings (user_id integer, name text, value text);
server_a# create publication users_pub for table users WITH (publish =
'insert');
server_a# create publication settings_pub for table settings;
...
server_b# create table users (user_id integer, name text);
server_b# create table settings (user_id integer, name text, value text);
server_b# create subscription usr_stt_sub connection '...' publication
users_pub, settings_pub;
...
server_a# create table s (trx_id integer, amount numeric);
server_a# COPY s FROM ...;