From 437ecd15880c833427ced9e3ebe3893d068f8478 Mon Sep 17 00:00:00 2001
From: Magnus Hagander <magnus@hagander.net>
Date: Sun, 20 Jan 2013 16:10:12 +0100
Subject: [PATCH] Clarify that streaming replication can be both async and sync
Josh Kupershmidt
---
doc/src/sgml/high-availability.sgml | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 62f72b40ae0..c29fe825315 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>
--
GitLab