How a 58-Table Subscription Crashed the Entire Replication Cluster

The first three services replicated without incident. Super ID had 2 tables. Floorplan had 4. Each subscription created its background worker, copied the initial data, and settled into steady-state streaming. I had 3 active subscriptions consuming 3 of the 6 available worker slots on the Central DB. Plenty of room. Then I added the Rightmove scraper. 58 tables. The subscription sat in "initializing" state for two hours. No errors in the application logs. No alerts. The pg_stat_subscription view showed a PID, which meant the worker was alive. But pg_subscription_rel told the real story: every table was stuck at i (initializing), none had transitioned to r (ready). The data wasn't flowing. What "Initializing" Actually Means PostgreSQL logical replication has two phases. Phase one is the initial table copy: the subscriber connects to the publisher and copies every row from every published table. Phase two is the streaming phase: ongoing WAL changes flow through the replication slot. The i