Re: replay pause vs. standby promotion
От | Fujii Masao |
---|---|
Тема | Re: replay pause vs. standby promotion |
Дата | |
Msg-id | ee53a324-4f3c-1d81-a74e-b9983f518c4e@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 0:17, Sergei Kornilov wrote: > Hello > >> I pushed the latest version of the patch. If you have further opinion >> about immediate promotion, let's keep discussing that! > > Thank you! > > Honestly, I forgot that the promotion is documented in high-availability.sgml as: > >> Before failover, any WAL immediately available in the archive or in pg_wal will be >> restored, but no attempt is made to connect to the master. > > I mistakenly thought that promote should be "immediately"... > >> If a promotion is triggered while recovery is paused, the paused state ends and a promotion continues. > > Could we add a few words in func.sgml to clarify the behavior? Especially for users from my example above. Something like: > >> If a promotion is triggered while recovery is paused, the paused state ends, replay of any WAL immediately available inthe 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? Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
В списке pgsql-hackers по дате отправления: