[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    How to handle logical replication 12->14, when our max_replication_slots gets overrun by inactive sy
From:       hubert depesz lubaczewski <depesz () depesz ! com>
Date:       2022-09-23 14:38:09
Message-ID: Yy3E0Qj5JLASvr7G () depesz ! com
[Download RAW message or body]

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



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic