Re: Add checkpoint and redo LSN to LogCheckpointEnd log message
От | Fujii Masao |
---|---|
Тема | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
Дата | |
Msg-id | b3b23cb7-9002-d6a3-2189-fa9ca99b0969@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Add checkpoint and redo LSN to LogCheckpointEnd log message
|
Список | pgsql-hackers |
On 2022/02/07 12:02, Kyotaro Horiguchi wrote: > - If any later checkpoint/restartpoint has been established, just skip > remaining task then return false. (!chkpt_was_latest) > (I'm not sure this can happen, though.) > > - we update control file only when archive recovery is still ongoing. This comment seems to conflict with what your PoC patch does. Because with the patch, ControlFile->checkPoint and ControlFile->checkPointCopyseem to be updated even when ControlFile->state != DB_IN_ARCHIVE_RECOVERY. I agree with what your PoC patch does for now. When we're not in archive recovery state, checkpoint and REDO locations inpg_control should be updated but min recovery point should be reset to invalid one (which instruments that subsequent crashrecovery should replay all available WAL files). > - Otherwise reset minRecoveryPoint then continue. > > Do you have any thoughts or opinions? Regarding chkpt_was_latest, whether the state is DB_IN_ARCHIVE_RECOVERY or not, if checkpoint and redo locations in pg_controlare updated, IMO we don't need to skip the "remaining tasks". Since those locations are updated and subsequentcrash recovery will start from that redo location, for example, ISTM that we can safely delete old WAL files priorto the redo location as the "remaining tasks". Thought? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: