Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
От | Fujii Masao |
---|---|
Тема | Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2 |
Дата | |
Msg-id | c85599fe-859e-308a-2393-6c1c4f533117@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2 (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
|
Список | pgsql-hackers |
On 2020/04/21 17:15, Kyotaro Horiguchi wrote: > At Mon, 20 Apr 2020 15:26:16 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in >> Patch attached. I will add this into the first CF for v14. > > - if (!fast_promoted) > + if (!promoted) > RequestCheckpoint(CHECKPOINT_END_OF_RECOVERY | > CHECKPOINT_IMMEDIATE | > CHECKPOINT_WAIT); > > If we don't find the checkpoint record just before, we don't insert > End-Of-Recovery record then run an immediate chekpoint. I think if we > nuke the non-fast promotion, shouldn't we insert the EOR record even > in that case? I'm not sure if that's safe. What if the server crashes before the checkpoint completes in that case? Since the last checkpoint record is not available, the subsequent crash recovery will fail. This would lead to that the server will never start up. Right? Currently ISTM that end-of-recovery-checkpoint is executed to avoid such trouble in that case. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: