From 9d90e2bdafbdeba037aa4fee3febe9f48201bf74 Mon Sep 17 00:00:00 2001
From: Amit Kapila
Date: Thu, 29 Aug 2024 08:56:52 +0530
Subject: Doc: Fix the ambiguity in the description of failover slots.
The failover slots ensure a seamless transition of a subscriber after the
standby is promoted. But the docs for it also explain the behavior of
asynchronous replication which can confuse the readers.
Reported-by: Masahiro Ikeda
Backpatch-through: 17
Discussion: https://postgr.es/m/OS3PR01MB6390B660F4198BB9745E0526B18B2@OS3PR01MB6390.jpnprd01.prod.outlook.com
---
doc/src/sgml/logical-replication.sgml | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
(limited to 'doc/src')
diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index bee7e02983b..bc095d01c00 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -701,10 +701,7 @@ ALTER SUBSCRIPTION
failover
parameter ensures a seamless transition of those subscriptions after the
standby is promoted. They can continue subscribing to publications on the
- new primary server without losing data. Note that in the case of
- asynchronous replication, there remains a risk of data loss for transactions
- committed on the former primary server but have yet to be replicated to the new
- primary server.
+ new primary server.
@@ -791,7 +788,7 @@ test_standby=# SELECT slot_name, (synced AND NOT temporary AND NOT conflicting)
If all the slots are present on the standby server and the result
(failover_ready) of the above SQL query is true, then
existing subscriptions can continue subscribing to publications now on the
- new primary server without losing data.
+ new primary server.
--
cgit v1.2.3