On Wed, Nov 30, 2022 at 7:40 PM Simon Riggs
<simon.riggs@enterprisedb.com> wrote:
> On Wed, 30 Nov 2022 at 03:50, Thomas Munro <thomas.munro@gmail.com> wrote:
> > I'm just curious, and not suggesting that 60s wakeups are a problem
> > for the polar ice caps, but why even time out at all? Are the latch
> > protocols involved not reliable enough? At a guess from a quick
> > glance, the walwriter's is but maybe the bgwriter could miss a wakeup
> > as it races against StrategyGetBuffer(), which means you might stay
> > asleep until the *next* buffer allocation, but that's already true I
> > think, and a 60s timeout is not much of a defence.
>
> That sounds reasonable.
>
> It does sound like we agree that the existing behavior of waking up
> every 5s or 2.5s is not good. I hope you will act to improve that.
>
> The approach taken in this patch, and others of mine, has been to
> offer a minimal change that achieves the objective of lengthy
> hibernation to save power.
>
> Removing the timeout entirely may not work in other circumstances I
> have not explored. Doing that requires someone to check it actually
> works, and for others to believe that check has occurred. For me, that
> is too time consuming to actually happen in this dev cycle, and time
> is part of the objective since perfect designs yet with unreleased
> code have no utility.
>
> <Simon enters lengthy hibernation>
<Thomas returns from aestivation>
Yeah, I definitely want to fix it. I just worry that 60s is so long
that it also needs that analysis work to be done to explain that it's
OK that we're a bit sloppy on noticing when to wake up, at which point
you might as well go to infinity.
