From 0f13d5c8a55115b69c4c21c258ed0db71671fc6d Mon Sep 17 00:00:00 2001 From: Shveta Malik Date: Mon, 7 Jul 2025 09:36:40 +0530 Subject: [PATCH] top-up-failover-document --- doc/src/sgml/logical-replication.sgml | 30 +++++++++++++++------------ 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml index 2b540972e36..0da52a983ed 100644 --- a/doc/src/sgml/logical-replication.sgml +++ b/doc/src/sgml/logical-replication.sgml @@ -788,28 +788,32 @@ HINT: To initiate replication, you must manually create the replication slot, e The first two steps in the above procedure are meant for a - PostgreSQL subscriber. A - non-PostgreSQL subscriber may have its own method - of identifying the slots used by its subscriptions. + PostgreSQL subscriber. It is recommended to + run these steps on each subscriber node that will be served by + the designated standby after failover, in order to obtain the complete + list of replication slots. This list can then be verified in Step 3 to + ensure failover readiness. Non-PostgreSQL + subscribers, on the other hand, may use their own methods to identify + the replication slots used by their subscriptions. - Sometimes it is required to confirm that all the subscribers, - PostgreSQL or - non-PostgreSQL, will be able to continue - replication after failing over to a given standby server, for example, in - case of a planned failover. In such a case use the following SQL, instead of - the first two steps above, to identify which replication slots on the primary - should be synced to the standby that we plan to promote. This query will - return the relevant replication slots associated with all the - failover-enabled subscriptions. + In some cases, such as during a planned failover, it is necessary to + confirm that all subscribers, whether PostgreSQL + or non-PostgreSQL, will be able to continue + replication after failover to a given standby server. In such scenarios, + use the following SQL, instead of performing the first two steps above, + to identify which replication slots on the primary need to be synced + to the standby that is intended for promotion. This query returns the + relevant replication slots associated with all the failover-enabled + subscriptions. /* primary # */ SELECT array_agg(quote_literal(r.slot_name)) AS slots FROM pg_replication_slots r - WHERE r.failover AND NOT r.temporary; + WHERE r.failover; slots ------- {'sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'} -- 2.34.1