Re: RecoveryWalAll and RecoveryWalStream wait events
От | Fujii Masao |
---|---|
Тема | Re: RecoveryWalAll and RecoveryWalStream wait events |
Дата | |
Msg-id | bacc5242-50e1-3e1e-550d-df393861a1bf@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: RecoveryWalAll and RecoveryWalStream wait events (Atsushi Torikoshi <atorik@gmail.com>) |
Ответы |
Re: RecoveryWalAll and RecoveryWalStream wait events
|
Список | pgsql-hackers |
On 2020/03/18 17:56, Atsushi Torikoshi wrote: > > > On Tue, Mar 17, 2020 at 11:55 AM Fujii Masao <masao.fujii@oss.nttdata.com <mailto: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. 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. --------------------- > 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? > 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. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
Вложения
В списке pgsql-hackers по дате отправления: