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
signature.asc
Description: PGP signature
