Re: RecoveryWalAll and RecoveryWalStream wait events - Mailing list pgsql-hackers

From Atsushi Torikoshi
Subject Re: RecoveryWalAll and RecoveryWalStream wait events
Date
Msg-id CACZ0uYFXtB3zYCW5p+nb9TXDnyUim6BctFaiBp7r4yUcfARCTQ@mail.gmail.com
Whole thread Raw
In response to Re: RecoveryWalAll and RecoveryWalStream wait events  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: RecoveryWalAll and RecoveryWalStream wait events  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List 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 by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Collation versioning
Next
From: Takashi Menjo
Date:
Subject: RE: [PoC] Non-volatile WAL buffer