Re: Inaccurate statement about log shipping replication mode

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