Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit0a2da52

Browse files
committed
Clarify that streaming replication can be both async and sync
Josh Kupershmidt
1 parent26d905a commit0a2da52

File tree

1 file changed

+8
-7
lines changed

1 file changed

+8
-7
lines changed

‎doc/src/sgml/high-availability.sgml

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -738,13 +738,14 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
738738
</para>
739739

740740
<para>
741-
Streaming replication is asynchronous, so there is still a small delay
742-
between committing a transaction in the primary and for the changes to
743-
become visible in the standby. The delay is however much smaller than with
744-
file-based log shipping, typically under one second assuming the standby
745-
is powerful enough to keep up with the load. With streaming replication,
746-
<varname>archive_timeout</> is not required to reduce the data loss
747-
window.
741+
Streaming replication is asynchronous by default
742+
(see <xref linkend="synchronous-replication">), in which case there is
743+
a small delay between committing a transaction in the primary and the
744+
changes becoming visible in the standby. This delay is however much
745+
smaller than with file-based log shipping, typically under one second
746+
assuming the standby is powerful enough to keep up with the load. With
747+
streaming replication, <varname>archive_timeout</> is not required to
748+
reduce the data loss window.
748749
</para>
749750

750751
<para>

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp