logical replication - who is managing replication slots created automatically during initial sync - Mailing list pgsql-general

From Avi Weinberg
Subject logical replication - who is managing replication slots created automatically during initial sync
Date
Msg-id DB9PR07MB7180EA18C0A832E3B59D18B8CB942@DB9PR07MB7180.eurprd07.prod.outlook.com
Whole thread Raw
List 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.

pgsql-general by date:

Previous
From: Justin Clift
Date:
Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
Next
From: Ram Pratap Maurya
Date:
Subject: After DB upgrade from PG13 to PG15 showing error