On 2020-Apr-28, Alvaro Herrera wrote: > On 2020-Apr-28, Kyotaro Horiguchi wrote: > > > > Anyway I think this patch should fix it also -- instead of adding a new > > > flag, we just rely on the existing flags (since do_checkpoint must have > > > been set correctly from the flags earlier in that block.) > > > > Since the added (!do_checkpoint) check is reached with > > do_checkpoint=false at server start and at archive_timeout intervals, > > the patch makes checkpointer run a busy-loop at that timings, and that > > loop lasts until a checkpoint is actually executed. > > > > What we need to do here is not forgetting the fact that the latch has > > been set even if the latch itself gets reset before reaching to > > WaitLatch. > > After a few more false starts :-) I think one easy thing we can do > without the additional boolean flag is to call SetLatch there in the > main loop if we see that ckpt_flags is nonzero.
I went back to "continue" instead of SetLatch, because it seems less wasteful, but I changed the previously "do_checkpoint" condition to rechecking ckpt_flags. We would not get in the busy loop in that case, because the condition is true when the next loop would take action and false otherwise. So I think this should fix the problem without causing any other issues. But if you do see problems with this, please let us know. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
