From 221e86b2a821b4f0d812448fbe879df242c6ca05 Mon Sep 17 00:00:00 2001 From: Laurenz Albe Date: Tue, 2 Sep 2025 09:24:06 +0200 Subject: [PATCH v2] Fix doc defining asynchronous replication The statement was factually wrong: WAL records can get shipped to the standby before the transaction commits. The key point is that the primary does not wait for the standby. Since the paragraph stresses the potential data loss, add a remark that synchronous replication can be used to avoid that problem. Author: Laurenz Albe Discussion: https://postgr.es/m/175578964049.806.14564779365418625473@wrigleys.postgresql.org --- doc/src/sgml/high-availability.sgml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index b47d8b4106e..041caba239d 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -528,7 +528,7 @@ protocol to make nodes agree on a serializable transactional order. It should be noted that log shipping is asynchronous, i.e., the WAL - records are shipped after transaction commit. As a result, there is a + records may be shipped after transaction commit. As a result, there is a window for data loss should the primary server suffer a catastrophic failure; transactions not yet shipped will be lost. The size of the data loss window in file-based log shipping can be limited by use of the @@ -536,7 +536,10 @@ protocol to make nodes agree on a serializable transactional order. as a few seconds. However such a low setting will substantially increase the bandwidth required for file shipping. Streaming replication (see ) - allows a much smaller window of data loss. + allows a much smaller window of data loss, and synchronous streaming + replication (see ) can + guarantee that no transaction is reported as committed before the + WAL records have reached the standby server. -- 2.51.0