How to handle logical replication 12->14, when our max_replication_slots gets overrun by inactive sync workers - Mailing list pgsql-general

From hubert depesz lubaczewski
Subject How to handle logical replication 12->14, when our max_replication_slots gets overrun by inactive sync workers
Date
Msg-id Yy3E0Qj5JLASvr7G@depesz.com
Whole thread Raw
List pgsql-general
Hi,
I reported a bug aobut it earlier, and from what I know it has been
fixed, but new release will come later.

For now I have this situation:

1. max_replication_slots is 50
2. database to replicate has 67 schemas, and ~ 26k tables.
3. schemas are split into 5 slots
4. pg14 side has max_sync_workers_per_subscription = 2

we start replication. within an hour all 50 replication slots on pg12
are used. 5 by our pg14 upgrade slots, and the other *45* by sync
workers, which are generally active = false.

at this moment all sync traffic dies (seen in network traffic data).

we tried to kill inactive sync workers - didn't help.

I tried to set max_sync_workers_per_subscription = 0, to avoid using
these extra workers, but it just seems to make slots sit there. 1 table
in each slot changed status to 'r', but all other are at 'i'.

Currently I'm running a test where all tables are in single slot, with
2 max_sync_workers_per_subscription but it will take "a while" to get it
to working state.

Is there anything we can do now?

I seem to have a case where the problem is 100% repeatable, so if anyone
has ideas I can test them fully.

Best regards,

depesz




pgsql-general by date:

Previous
From: Jerry Sievers
Date:
Subject: Re: pg_dump failed with error code 255, but I don't see why
Next
From: Mohammed falih
Date:
Subject: Re: i added Arabic Dictionary but how I know i'm using it