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
|
| Список | 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 по дате отправления: