Re: RecoveryWalAll and RecoveryWalStream wait events

On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
wrote:

>
> I meant the following part in the doc.
>
> ---------------------
> At startup, the standby begins by restoring all WAL available in the
> archive
> location, calling restore_command. Once it reaches the end of WAL available
> there and restore_command fails, it tries to restore any WAL available in
> the
> pg_wal directory. If that fails, and streaming replication has been
> configured,
> the standby tries to connect to the primary server and start streaming WAL
> from
> the last valid record found in archive or pg_wal. If that fails or
> streaming
> replication is not configured, or if the connection is later disconnected,
> the standby goes back to step 1 and tries to restore the file from the
> archive
> again. This loop of retries from the archive, pg_wal, and via streaming
> replication goes on until the server is stopped or failover is triggered
> by a
> trigger file.
> ---------------------
>
>
Thanks!

> > 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?
>
> No, I think for now. But you'd like to improve the docs?
>

I'll do it.

> > 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.
>
> Ok, I changed that from "local" to "pg_wal" in the patch for
> the master. Attached is the updated version of the patch.
> If you're OK with this, I'd like to commit two patches that I posted
> in this thread.

Thanks for your modification and it looks good to me.

Regards,

--
Torikoshi Atsushi