0001-top-up-failover-document.patch

From 0f13d5c8a55115b69c4c21c258ed0db71671fc6d Mon Sep 17 00:00:00 2001
From: Shveta Malik <shveta.malik@gmail.com>
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
 
   <para>
    The first two steps in the above procedure are meant for a
-   <productname>PostgreSQL</productname> subscriber. A
-   non-<productname>PostgreSQL</productname> subscriber may have its own method
-   of identifying the slots used by its subscriptions.
+   <productname>PostgreSQL</productname> 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-<productname>PostgreSQL</productname>
+   subscribers, on the other hand, may use their own methods to identify
+   the replication slots used by their subscriptions.
   </para>
 
   <para>
-   Sometimes it is required to confirm that all the subscribers,
-   <productname>PostgreSQL</productname> or
-   non-<productname>PostgreSQL</productname>, 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 <productname>PostgreSQL</productname>
+   or non-<productname>PostgreSQL</productname>, 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.
   </para>
 
    <para>
 <programlisting>
 /* 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