Re: Inaccurate statement about log shipping replication mode
От | Michael Paquier |
---|---|
Тема | Re: Inaccurate statement about log shipping replication mode |
Дата | |
Msg-id | aLTYpFWPT8v5JJh1@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Inaccurate statement about log shipping replication mode (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Inaccurate statement about log shipping replication mode
Re: Inaccurate statement about log shipping replication mode |
Список | pgsql-docs |
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
Вложения
В списке pgsql-docs по дате отправления: