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

From Fujii Masao
Subject Re: RecoveryWalAll and RecoveryWalStream wait events
Date
Msg-id aab7b94f-8140-48eb-3e31-698be55275d5@oss.nttdata.com
Whole thread Raw
In response to Re: RecoveryWalAll and RecoveryWalStream wait events  (Atsushi Torikoshi <atorik@gmail.com>)
Responses Re: RecoveryWalAll and RecoveryWalStream wait events  (Atsushi Torikoshi <atorik@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Thunder
Date:
Subject: Re:Standby got fatal after the crash recovery
Next
From: Thunder
Date:
Subject: Re:Re:Standby got fatal after the crash recovery