Re: Reducing power consumption on idle servers

On Thu, 24 Mar 2022 at 07:16, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:

> > Most of these timeouts are a bad idea and should not exist. We repeatedly have
> > had bugs where we were missing wakeups etc but those bugs were harder to
>
> I basically agree to this.

As a general point, maybe. But we have a lot of procs doing a lot of
polling and we are unlikely to change that anytime soon.

> > notice because of timeouts. I'm against entrenching this stuff further.
>
> For example, pgarch.c theoretically doesn't need hibernate, since it
> has an apparent trigger event and a terminal condition. What we need
> to do about archiver is to set timeout only when it didn't reach the
> lastest finished segment at an iteration. (this might need additional
> shared memory use, though..)

archiver is not the important thing here. If there is objection to
that section of code we can remove that.

> I'm not sure about bgwriter, walwriter and logical replication stuff...

I am sure. bgwriter, walwriter and logical worker need action from us
to allow them to hibernate in a sensible way that allows powersaving.

> I think Thomas is wroking on the walreceiver timeout stuff.

Yes, he is. I have no problem going with what he advocates, if others agree.

However, that fix does not solve the whole problem, since many other
procs also need fixing.

The proposals of this patch are the following, each of which can be
independently accepted/rejected:
1. fix the sleep pattern of bgwriter, walwriter and logical worker
(directly affects powersave)
2. deprecate promote_trigger_file, which then allows us to fix the
sleep for startup process (directly affects powersave)
3. treat hibernation in all procs the same, for simplicity, and to
make sure we don't forget one later
4. provide a design pattern for background worker extensions to
follow, so as to encourage powersaving

Please don't reject the whole patch because you disagree with part
(3), it is not that important.

Thanks

--
Simon Riggs http://www.EnterpriseDB.com/