Re: RecoveryWalAll and RecoveryWalStream wait events

Поиск
Список
Период
Сортировка
От Atsushi Torikoshi
Тема Re: RecoveryWalAll and RecoveryWalStream wait events
Дата
Msg-id CACZ0uYFXtB3zYCW5p+nb9TXDnyUim6BctFaiBp7r4yUcfARCTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RecoveryWalAll and RecoveryWalStream wait events  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: RecoveryWalAll and RecoveryWalStream wait events  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers


On Tue, Mar 17, 2020 at 11:55 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>  >    Waiting when WAL data is not available from any kind of sources
>  >    (local, archive or stream) before trying again to retrieve WAL data,
>
> I think 'local' means pg_wal here, but the comment on
> WaitForWALToBecomeAvailable() says checking pg_wal in
> standby mode is 'not documented', so I'm a little bit worried
> that users may be confused.

This logic seems to be documented in high-availability.sgml.

Thanks! I didn't notice it.
I think you mean the below sentence.

>  The standby server will also attempt to restore any WAL found in the standby cluster's pg_wal directory.

It seems the comment on WaitForWALToBecomeAvailable() 
does not go along with the high-availability.sgml, do we need
modification on the comment on the function?
Or do I misunderstand something?

But, anyway, you think that "pg_wal" should be used instead 
of "local" here?

I don't have special opinion here.
It might be better because high-availability.sgml does not use
"local" but "pg_wal" for the explanation,  but I also feel it's
obvious in this context.


Regards,

--
Torikoshi Atsushi

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Collation versioning
Следующее
От: Takashi Menjo
Дата:
Сообщение: RE: [PoC] Non-volatile WAL buffer