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

From Simon Riggs
Subject Re: Reducing power consumption on idle servers
Date
Msg-id CANbhV-Fhv4DUrv5UiTHyHOj7TNQTyejKfX1v1NNG4ZU+J_RNFQ@mail.gmail.com
Whole thread Raw
In response to Re: Reducing power consumption on idle servers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Reducing power consumption on idle servers
List pgsql-hackers
On Thu, 17 Nov 2022 at 20:38, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Nov 17, 2022 at 2:55 AM Simon Riggs
> <simon.riggs@enterprisedb.com> wrote:
> > No, it will have a direct effect only on people using promote_trigger_file
> > who do not read and act upon the deprecation notice before upgrading
> > by making a one line change to their failover scripts.
>
> TBH, I wonder if we shouldn't just nuke promote_trigger_file.
> pg_promote was added in 2018, and pg_ctl promote was added in 2011. So
> even if we haven't said promote_trigger_file was deprecated, it hasn't
> been the state-of-the-art way of doing this in a really long time. If
> we think that there are still a lot of people using it, or if popular
> tools are relying on it, then perhaps a deprecation period is
> warranted anyway. But I think we should at least consider the
> possibility that it's OK to just get rid of it right away.

I agree. I can't see a reason to keep it anymore.

I'm nervous about not having any wakeup at all, but since we are
removing the parameter there is no other reason not to do as Andres
suggests.

New version attached, which assumes that the SIGALRMs are silenced on
the other thread.

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

Attachment

pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: allowing for control over SET ROLE
Next
From: Alvaro Herrera
Date:
Subject: Re: MERGE regress test