From: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
---|---|
To: | pgsql-general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | How to handle logical replication 12->14, when our max_replication_slots gets overrun by inactive sync workers |
Date: | 2022-09-23 14:38:09 |
Message-ID: | Yy3E0Qj5JLASvr7G@depesz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mohammed falih | 2022-09-23 20:34:18 | Re: i added Arabic Dictionary but how I know i'm using it |
Previous Message | Jerry Sievers | 2022-09-23 04:02:44 | Re: pg_dump failed with error code 255, but I don't see why |