public inbox for [email protected]
help / color / mirror / Atom feedFrom: Laurenz Albe <[email protected]>
To: Michael Paquier <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: Inaccurate statement about log shipping replication mode
Date: Tue, 02 Sep 2025 09:28:30 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Mon, 2025-09-01 at 08:20 +0900, Michael Paquier wrote:
> On Wed, Aug 27, 2025 at 02:13:21PM +0200, Laurenz Albe wrote:
> > Here is a patch for that.
> > --- a/doc/src/sgml/high-availability.sgml
> > +++ b/doc/src/sgml/high-availability.sgml
> > @@ -527,8 +527,8 @@ protocol to make nodes agree on a serializable transactional order.
> > </para>
> >
> > <para>
> > - 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
> > + It should be noted that log shipping is asynchronous, i.e., the primary server does
> > + not wait until the standby receives the data. 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
>
> Yep, the original statement is rather inexact. Now, your new wording
> does not make me really comfortable with the case of cascading stanbys
> in scope, because the asynchronous property applies to them all the
> time.
>
> Hmm. I'd suggest to use a simpler reformulatione, like this one to
> outline that there is no relationship between the timing of a
> transaction commit and the timing where the commit records are flushed
> on a standby server:
> It should be noted that log shipping is asynchronous, i.e., the WAL
> records may be shipped after transaction commit.
That is a less invasive change and probably preferable.
The attached patch does it like you suggested.
I noticed that the paragraph speaks about the asynchronicity of replication
and the potential of data loss, so I couldn't resist the temptation to add
a remark that synchronous streaming replication can avoid that problem.
Yours,
Laurenz Albe
Attachments:
[text/x-patch] v2-0001-Fix-doc-defining-asynchronous-replication.patch (2.1K, 2-v2-0001-Fix-doc-defining-asynchronous-replication.patch)
download | inline diff:
From 221e86b2a821b4f0d812448fbe879df242c6ca05 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <[email protected]>
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 <[email protected]>
Discussion: https://postgr.es/m/[email protected]
---
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.
<para>
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 <xref linkend="streaming-replication"/>)
- allows a much smaller window of data loss.
+ allows a much smaller window of data loss, and synchronous streaming
+ replication (see <xref linkend="synchronous-replication"/>) can
+ guarantee that no transaction is reported as committed before the
+ WAL records have reached the standby server.
</para>
<para>
--
2.51.0
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Inaccurate statement about log shipping replication mode
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox