Re: RecoveryWalAll and RecoveryWalStream wait events
Atsushi Torikoshi <atorik@gmail.com>
From: Atsushi Torikoshi <atorik@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-03-18T08:56:38Z
Lists: 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
Commits
-
Rename the recovery-related wait events.
- 1d253bae57fc 13.0 landed
-
Correct the descriptions of recovery-related wait events in docs.
- f4efb46d2230 10.13 landed
- 375aa3fc2cb2 11.8 landed
- 21b1cb6a786e 12.3 landed
- dbe0d9892c33 13.0 landed