From b48c68914b687c150447e8e2c382374d754a20b5 Mon Sep 17 00:00:00 2001 From: Masahiro Ikeda Date: Mon, 26 Aug 2024 16:42:40 +0900 Subject: [PATCH v1] fix documentation related to synchronized_standby_slots --- doc/src/sgml/logical-replication.sgml | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml index bee7e02983b..a355ad34275 100644 --- a/doc/src/sgml/logical-replication.sgml +++ b/doc/src/sgml/logical-replication.sgml @@ -701,18 +701,17 @@ 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 without losing data. - Because the slot synchronization logic copies asynchronously, it is - necessary to confirm that replication slots have been synced to the standby - server before the failover happens. To ensure a successful failover, the - standby server must be ahead of the subscriber. This can be achieved by - configuring + Note that 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 even + in the case of synchronous physical replication. Because the slot synchronization + logic copies asynchronously, it is necessary to confirm that replication slots + have been synced to the standby server before the failover happens. To ensure a + successful failover, the standby server must be ahead of the subscriber. This + can be achieved by configuring synchronized_standby_slots. -- 2.34.1