Re: RecoveryWalAll and RecoveryWalStream wait events

Fujii Masao <masao.fujii@oss.nttdata.com>

From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Atsushi Torikoshi <atorik@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-03-17T02:55:43Z
Lists: pgsql-hackers

On 2020/03/15 0:06, Atsushi Torikoshi wrote:
> On 2020/02/19 21:46 Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>>:
>  >> I agree to the former, I think RecoveryWalInterval works well enough.
>  >RecoveryWalInterval sounds confusing to me...
> 
> IMHO as a user, I prefer RecoveryRetrieveRetryInterval because
> it's easy to understand this wait_event is related to the
> parameter 'wal_retrieve_retry_interval'.
> 
> Also from the point of balance, the explanation of
> RecoveryRetrieveRetryInterval is lengthy, but I
> sometimes feel explanations of wait_events in the
> manual are so simple that it's hard to understand
> well.

+1 to document them more. It's not easy task, though..

>  >    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.
But, anyway, you think that "pg_wal" should be used instead of "local" here?

Regards,

-- 
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters



Commits

  1. Rename the recovery-related wait events.

  2. Correct the descriptions of recovery-related wait events in docs.