Message-ID: <c0e1a5b32831e5a6a0d1febdc99e755d98471807.camel@cybertec.at>
Subject: Re: Inaccurate statement about log shipping replication mode
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Michael Paquier <michael@paquier.xyz>
Cc: artem.gavrilov@percona.com, pgsql-docs@lists.postgresql.org
Date: Tue, 02 Sep 2025 09:28:30 +0200
In-Reply-To: <aLTYpFWPT8v5JJh1@paquier.xyz>
References: <175578964049.806.14564779365418625473@wrigleys.postgresql.org>
	 <568ff8638e011b2726d06a4b95124ec51ee1e5af.camel@cybertec.at>
	 <a67687e233188a43a80b55c4ab8e1115bf2bd947.camel@cybertec.at>
	 <aLTYpFWPT8v5JJh1@paquier.xyz>
Content-Type: multipart/mixed; boundary="=-LtBHAOlsxAT6VZUzBhvI"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/c0e1a5b32831e5a6a0d1febdc99e755d98471807.camel%40cybertec.at>
Precedence: bulk

--=-LtBHAOlsxAT6VZUzBhvI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 tran=
sactional order.
> >    </para>
> > =20
> >    <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 pri=
mary server does
> > +   not wait until the standby receives the data.  As a result, there i=
s a
> >     window for data loss should the primary server suffer a catastrophi=
c
> >     failure; transactions not yet shipped will be lost.  The size of th=
e
> >     data loss window in file-based log shipping can be limited by use o=
f the
>=20
> 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.
>=20
> 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

--=-LtBHAOlsxAT6VZUzBhvI
Content-Disposition: attachment;
	filename="v2-0001-Fix-doc-defining-asynchronous-replication.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch;
	name="v2-0001-Fix-doc-defining-asynchronous-replication.patch";
	charset="UTF-8"

RnJvbSAyMjFlODZiMmE4MjFiNGYwZDgxMjQ0OGZiZTg3OWRmMjQyYzZjYTA1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMYXVyZW56IEFsYmUgPGxhdXJlbnouYWxiZUBjeWJlcnRlYy5h
dD4KRGF0ZTogVHVlLCAyIFNlcCAyMDI1IDA5OjI0OjA2ICswMjAwClN1YmplY3Q6IFtQQVRDSCB2
Ml0gRml4IGRvYyBkZWZpbmluZyBhc3luY2hyb25vdXMgcmVwbGljYXRpb24KClRoZSBzdGF0ZW1l
bnQgd2FzIGZhY3R1YWxseSB3cm9uZzogV0FMIHJlY29yZHMgY2FuIGdldCBzaGlwcGVkCnRvIHRo
ZSBzdGFuZGJ5IGJlZm9yZSB0aGUgdHJhbnNhY3Rpb24gY29tbWl0cy4gIFRoZSBrZXkgcG9pbnQK
aXMgdGhhdCB0aGUgcHJpbWFyeSBkb2VzIG5vdCB3YWl0IGZvciB0aGUgc3RhbmRieS4KClNpbmNl
IHRoZSBwYXJhZ3JhcGggc3RyZXNzZXMgdGhlIHBvdGVudGlhbCBkYXRhIGxvc3MsIGFkZCBhCnJl
bWFyayB0aGF0IHN5bmNocm9ub3VzIHJlcGxpY2F0aW9uIGNhbiBiZSB1c2VkIHRvIGF2b2lkIHRo
YXQKcHJvYmxlbS4KCkF1dGhvcjogTGF1cmVueiBBbGJlIDxsYXVyZW56LmFsYmVAY3liZXJ0ZWMu
YXQ+CkRpc2N1c3Npb246IGh0dHBzOi8vcG9zdGdyLmVzL20vMTc1NTc4OTY0MDQ5LjgwNi4xNDU2
NDc3OTM2NTQxODYyNTQ3M0B3cmlnbGV5cy5wb3N0Z3Jlc3FsLm9yZwotLS0KIGRvYy9zcmMvc2dt
bC9oaWdoLWF2YWlsYWJpbGl0eS5zZ21sIHwgNyArKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwgNSBp
bnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9o
aWdoLWF2YWlsYWJpbGl0eS5zZ21sIGIvZG9jL3NyYy9zZ21sL2hpZ2gtYXZhaWxhYmlsaXR5LnNn
bWwKaW5kZXggYjQ3ZDhiNDEwNmUuLjA0MWNhYmEyMzlkIDEwMDY0NAotLS0gYS9kb2Mvc3JjL3Nn
bWwvaGlnaC1hdmFpbGFiaWxpdHkuc2dtbAorKysgYi9kb2Mvc3JjL3NnbWwvaGlnaC1hdmFpbGFi
aWxpdHkuc2dtbApAQCAtNTI4LDcgKzUyOCw3IEBAIHByb3RvY29sIHRvIG1ha2Ugbm9kZXMgYWdy
ZWUgb24gYSBzZXJpYWxpemFibGUgdHJhbnNhY3Rpb25hbCBvcmRlci4KIAogICA8cGFyYT4KICAg
IEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGxvZyBzaGlwcGluZyBpcyBhc3luY2hyb25vdXMsIGku
ZS4sIHRoZSBXQUwKLSAgIHJlY29yZHMgYXJlIHNoaXBwZWQgYWZ0ZXIgdHJhbnNhY3Rpb24gY29t
bWl0LiBBcyBhIHJlc3VsdCwgdGhlcmUgaXMgYQorICAgcmVjb3JkcyBtYXkgYmUgc2hpcHBlZCBh
ZnRlciB0cmFuc2FjdGlvbiBjb21taXQuICBBcyBhIHJlc3VsdCwgdGhlcmUgaXMgYQogICAgd2lu
ZG93IGZvciBkYXRhIGxvc3Mgc2hvdWxkIHRoZSBwcmltYXJ5IHNlcnZlciBzdWZmZXIgYSBjYXRh
c3Ryb3BoaWMKICAgIGZhaWx1cmU7IHRyYW5zYWN0aW9ucyBub3QgeWV0IHNoaXBwZWQgd2lsbCBi
ZSBsb3N0LiAgVGhlIHNpemUgb2YgdGhlCiAgICBkYXRhIGxvc3Mgd2luZG93IGluIGZpbGUtYmFz
ZWQgbG9nIHNoaXBwaW5nIGNhbiBiZSBsaW1pdGVkIGJ5IHVzZSBvZiB0aGUKQEAgLTUzNiw3ICs1
MzYsMTAgQEAgcHJvdG9jb2wgdG8gbWFrZSBub2RlcyBhZ3JlZSBvbiBhIHNlcmlhbGl6YWJsZSB0
cmFuc2FjdGlvbmFsIG9yZGVyLgogICAgYXMgYSBmZXcgc2Vjb25kcy4gIEhvd2V2ZXIgc3VjaCBh
IGxvdyBzZXR0aW5nIHdpbGwKICAgIHN1YnN0YW50aWFsbHkgaW5jcmVhc2UgdGhlIGJhbmR3aWR0
aCByZXF1aXJlZCBmb3IgZmlsZSBzaGlwcGluZy4KICAgIFN0cmVhbWluZyByZXBsaWNhdGlvbiAo
c2VlIDx4cmVmIGxpbmtlbmQ9InN0cmVhbWluZy1yZXBsaWNhdGlvbiIvPikKLSAgIGFsbG93cyBh
IG11Y2ggc21hbGxlciB3aW5kb3cgb2YgZGF0YSBsb3NzLgorICAgYWxsb3dzIGEgbXVjaCBzbWFs
bGVyIHdpbmRvdyBvZiBkYXRhIGxvc3MsIGFuZCBzeW5jaHJvbm91cyBzdHJlYW1pbmcKKyAgIHJl
cGxpY2F0aW9uIChzZWUgPHhyZWYgbGlua2VuZD0ic3luY2hyb25vdXMtcmVwbGljYXRpb24iLz4p
IGNhbgorICAgZ3VhcmFudGVlIHRoYXQgbm8gdHJhbnNhY3Rpb24gaXMgcmVwb3J0ZWQgYXMgY29t
bWl0dGVkIGJlZm9yZSB0aGUKKyAgIFdBTCByZWNvcmRzIGhhdmUgcmVhY2hlZCB0aGUgc3RhbmRi
eSBzZXJ2ZXIuCiAgIDwvcGFyYT4KIAogICA8cGFyYT4KLS0gCjIuNTEuMAoK


--=-LtBHAOlsxAT6VZUzBhvI--