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.
--
Michael
