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
