Re: Possible corruption by CreateRestartPoint at promotion
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Possible corruption by CreateRestartPoint at promotion |
Дата | |
Msg-id | 20220428.114357.476887320744154615.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Possible corruption by CreateRestartPoint at promotion (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Possible corruption by CreateRestartPoint at promotion
|
Список | pgsql-hackers |
At Thu, 28 Apr 2022 09:12:13 +0900, Michael Paquier <michael@paquier.xyz> wrote in > On Wed, Apr 27, 2022 at 11:09:45AM -0700, Nathan Bossart wrote: > > On Wed, Apr 27, 2022 at 02:16:01PM +0900, Michael Paquier wrote: > >> - if (ControlFile->state == DB_IN_ARCHIVE_RECOVERY && > >> - ControlFile->checkPointCopy.redo < lastCheckPoint.redo) > >> - { > >> 7ff23c6 has removed the last call to CreateCheckpoint() outside the > >> checkpointer, meaning that there is one less concurrent race to worry > >> about, but I have to admit that this change, to update the control > >> file's checkPoint and checkPointCopy even if we don't check after > >> ControlFile->checkPointCopy.redo < lastCheckPoint.redo would make the > >> code less robust in ~14. So I am questioning whether a backpatch > >> is actually worth the risk here. > > > > IMO we should still check this before updating ControlFile to be safe. > > Sure. Fine by me to play it safe. Why do we consider concurrent check/restart points here while we don't consider the same for ControlFile->checkPointCopy? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: