Re: Reducing power consumption on idle servers - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Reducing power consumption on idle servers
Date
Msg-id CALj2ACXc7+uM=CmtZhrvySCOqwTLc1SFnBy8_i25TDcbv5cmzg@mail.gmail.com
Whole thread Raw
In response to Re: Reducing power consumption on idle servers  (Simon Riggs <simon.riggs@enterprisedb.com>)
Responses Re: Reducing power consumption on idle servers
Re: Reducing power consumption on idle servers
List pgsql-hackers
On Wed, Nov 16, 2022 at 8:35 PM Simon Riggs
<simon.riggs@enterprisedb.com> wrote:
>
> On Wed, 16 Nov 2022 at 12:47, Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> >
> > On Wed, Nov 16, 2022 at 2:34 PM Simon Riggs
> > <simon.riggs@enterprisedb.com> wrote:
> > >
> > > Reposting v6 now so that patch tester doesn't think this has failed
> > > when the patch on other thread gets applied.
> >
> > Intention of the patch, that is, to get rid of promote_trigger_file
> > GUC sometime in future, looks good to me. However, the timeout change
> > to 60 sec from 5 sec seems far-reaching. While it discourages the use
> > of the GUC, it can impact many existing production servers that still
> > rely on promote_trigger_file as it can increase the failover times
> > impacting SLAs around failover.
>
> The purpose of 60s is to allow for power reduction, so 5s won't do.

I understand. I know it's a bit hard to measure the power savings, I'm
wondering if there's any info, maybe not necessarily related to
postgres, but in general how much power gets saved if a certain number
of waits/polls/system calls are reduced.

> promote_trigger_file is not tested and there are better ways, so
> deprecating it in this release is fine.

Hm, but..

> Anyone that relies on it can update their mechanisms to a supported
> one with a one-line change. Realistically, anyone using it won't be on
> the latest release anyway, at least for a long time, since if they use
> manual methods then they are well behind the times.

I may be overly pessimistic here - the change from 5 sec to 60 sec for
detecting promote_trigger_file will have a direct impact on failovers
I believe. After upgrading to the version with 60 sec waiting,
there'll be an increase in failover times if the developers miss to
see the deprecation info about promote_trigger_file. I'm not sure
what's the best way to discourage using promote_trigger_file. Maybe
the change from 5 sec to 60 sec is the way. I'm not really sure.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Assertion failure with barriers in parallel hash join
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication