Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux