How to handle logical replication 12->14, when our max_replication_slots gets overrun by inactive sync workers
В списке pgsql-general по дате отправления:
| От | hubert depesz lubaczewski |
|---|---|
| Тема | How to handle logical replication 12->14, when our max_replication_slots gets overrun by inactive sync workers |
| Дата | |
| Msg-id | Yy3E0Qj5JLASvr7G@depesz.com обсуждение |
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера