On 2020/03/18 22:37, Atsushi Torikoshi wrote:
On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao <masao.fu...@oss.nttdata.com <mailto:masao.fu...@oss.nttdata.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.
Pushed! Thanks a lot! Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
