Re: replay pause vs. standby promotion
От | Fujii Masao |
---|---|
Тема | Re: replay pause vs. standby promotion |
Дата | |
Msg-id | 862dceb8-d895-053a-d429-4f5461b392d7@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: replay pause vs. standby promotion (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re: replay pause vs. standby promotion
|
Список | pgsql-hackers |
On 2020/03/25 19:42, Sergei Kornilov wrote: > Hi > >>> Could we add a few words in func.sgml to clarify the behavior? Especially for users from my example above. Somethinglike: >>> >>>> If a promotion is triggered while recovery is paused, the paused state ends, replay of any WAL immediately availablein the archive or in pg_wal will be continued and then a promotion will be completed. >> >> This description is true if pause is requested by pg_wal_replay_pause(), >> but not if recovery target is reached and pause is requested by >> recovery_target_action=pause. In the latter case, even if there are WAL data >> avaiable in pg_wal or archive, they are not replayed, i.e., the promotion >> completes immediately. Probably we should document those two cases >> explicitly to avoid the confusion about a promotion and recovery pause? > > This is description for pg_wal_replay_pause, but actually we suggest to call pg_wal_replay_resume in recovery_target_action=pause...So, I agree, we need to document both cases. > > PS: I think we have inconsistent behavior here... Read wal during promotion from local pg_wal AND call restore_command,but ignore walreceiver also seems strange for my DBA hat... If we don't ignore walreceiver and does try to connect to the master, a promotion and recovery cannot end forever since new WAL data can be streamed. You think this behavior is more consistent? IMO it's valid to replay all the WAL data available to avoid data loss before a promotion completes. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
В списке pgsql-hackers по дате отправления: