From 0a2da5282a2372b651e2096f16d97d6029e5f54f Mon Sep 17 00:00:00 2001 From: Magnus Hagander 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 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' - 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, - archive_timeout is not required to reduce the data loss - window. + Streaming replication is asynchronous by default + (see ), 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, archive_timeout is not required to + reduce the data loss window. -- 2.40.0