At Tue, 6 Sep 2022 14:02:53 +0300, "Anton A. Melnikov" <aamelni...@inbox.ru> wrote in > Can we treat such behavior as a bug?
Depends on how we see the counter value. I think this can be annoying but not a bug. CreateRestartPoint already handles that case. While standby is well catching up, startup may make requests once per segment switch while primary is running the latest checkpoint since standby won't receive a checkpoint record until the primary ends the last checkpoint. > If so it seems possible to check if a creating of restartpoint is > obviously impossible before sending request and don't send it at all > if so. > > The patch applied tries to fix it. It lets XLogPageRead run the same check with what CreateRestartPoint does, so it basically works (it is forgetting a lock, though. The reason for omitting the lock in CreateRestartPoint is that it knows checkopinter is the only updator of the shared variable.). I'm not sure I like that for the code duplication. I'm not sure we need to fix that but if we do that, I would impletent IsNewCheckPointWALRecs() using XLogCtl->RedoRecPtr and XLogCtl->lastCheckPoint.redo instead since they are protected by the same lock, and they work more correct way, that is, that can avoid restartpoint requests while the last checkpoint is running. And I would rename it as RestartPointAvailable() or something like that. Or I might want to add XLogRestartpointNeeded(readSegNo) to reduce the required number of info_lck by reading XLogCtl members at once. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
