logical replication - who is managing replication slots created automatically during initial sync

From: Avi Weinberg <AviW(at)gilat(dot)com>
To: pgsql-generallists(dot)postgresql(dot)org <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: logical replication - who is managing replication slots created automatically during initial sync
Date: 2024-08-27 06:53:42
Message-ID: DB9PR07MB7180EA18C0A832E3B59D18B8CB942@DB9PR07MB7180.eurprd07.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Experts

I have seen that logical replication slots created automatically by Postgres during initial sync (a slot per table), are marked as "wal_status = lost" and "active = false".
1. Who is responsible for removing those faulty replication slots?
2. Can a slot with "wal_status = lost" recover from this state?
3. Do I need to drop the subscription in such a case?
4. Are those replication slots that synchronize a single table each, use a connection from "max_connections" and replication slot from "max_logical_replication_slots"?
5. If I sync many tables will it be better to increase the number of max_logical_replication_slots or to have some of the tables "wait" for other tables to complete and release the replication slot for them to use.

I'm using Postgres 15.2
slot_name plugin slot_type datoid database temporary active active_pid xmin catalog_xmin restart_lsn confirmed_flush_lsn wal_status safe_wal_size two_phase
pg_8034820_sync_8033089_7371741997992267844 pgoutput logical 16707 aaa_db FALSE FALSE NULL NULL 295098502 NULL D9/EB7317B0 lost NULL FALSE
pg_6839631_sync_6837833_7371741997992267844 pgoutput logical 16707 aaa_db FALSE FALSE NULL NULL 288349892 NULL D2/80068A78 lost NULL FALSE

Thanks!

IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.

Browse pgsql-general by date

  From Date Subject
Next Message Ram Pratap Maurya 2024-08-27 08:50:36 After DB upgrade from PG13 to PG15 showing error
Previous Message Justin Clift 2024-08-27 06:00:13 Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.