From: | Don Seiler <don(at)seiler(dot)us> |
---|---|
To: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Runaway Initial Table Syncs in Logical Replication? |
Date: | 2023-08-03 19:24:04 |
Message-ID: | CAHJZqBAOO-c-9f+cCUae76vxPt77g82G_HFYa5Va1KK6uTUN4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Logical Rep question. Publisher is PG12 on Ubuntu 18.04, subscriber is PG15
on Ubuntu 22.04.
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.
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?
--
Don Seiler
www.seiler.us
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2023-08-03 19:45:39 | Aw: Re: question on auto_explain |
Previous Message | Karsten Hilbert | 2023-08-03 16:53:28 | Aw: Re: question on auto_explain |