From: Magnus Hagander <magnus@hagander.net>
Date: Sun, 20 Jan 2013 15:10:12 +0000 (+0100)
Subject: Clarify that streaming replication can be both async and sync
X-Git-Tag: REL9_3_BETA1~470
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=0a2da5282a2372b651e2096f16d97d6029e5f54f;p=postgresql

Clarify that streaming replication can be both async and sync

Josh Kupershmidt
---

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index e8342858c9..c8f6fa8a54 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -738,13 +738,14 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
    </para>
 
    <para>
-    Streaming replication is asynchronous, so there is still a small delay
-    between committing a transaction in the primary and for the changes to
-    become visible in the standby. The delay is however much smaller than with
-    file-based log shipping, typically under one second assuming the standby
-    is powerful enough to keep up with the load. With streaming replication,
-    <varname>archive_timeout</> is not required to reduce the data loss
-    window.
+    Streaming replication is asynchronous by default
+    (see <xref linkend="synchronous-replication">), in which case there is
+    a small delay between committing a transaction in the primary and the
+    changes becoming visible in the standby. This delay is however much
+    smaller than with file-based log shipping, typically under one second
+    assuming the standby is powerful enough to keep up with the load. With
+    streaming replication, <varname>archive_timeout</> is not required to
+    reduce the data loss window.
    </para>
 
    <para>