Re: Reducing power consumption on idle servers - Mailing list pgsql-hackers
From | Thomas Munro |
---|---|
Subject | Re: Reducing power consumption on idle servers |
Date | |
Msg-id | CA+hUKGLaDk4R95hfk044hpaomcA3tEdLddsH14dD11jWQkZ8sA@mail.gmail.com Whole thread Raw |
In response to | Re: Reducing power consumption on idle servers (Ian Lawrence Barwick <barwick@gmail.com>) |
Responses |
Re: Reducing power consumption on idle servers
Re: Reducing power consumption on idle servers |
List | pgsql-hackers |
On Sun, Nov 27, 2022 at 6:15 PM Ian Lawrence Barwick <barwick@gmail.com> wrote: > 2022年11月22日(火) 5:50 Laurenz Albe <laurenz.albe@cybertec.at>: > > On Mon, 2022-11-21 at 12:11 -0500, Tom Lane wrote: > > > Robert Haas <robertmhaas@gmail.com> writes: > > > > The reason that I pushed back -- not as successfully as I would have > > > > liked -- on the changes to pg_stop_backup / pg_start_backup is that I > > > > know there are people using the old method successfully, and it's not > > > > just a 1:1 substitution. Here I don't, and it is. I'm totally open to > > > > the feedback that such people exist and to hearing why adopting one of > > > > the newer methods would be a problem for them, if that's the case. But > > > > if there's no evidence that such people exist or that changing is a > > > > problem for them, I don't think waiting 5 years on principle is good > > > > for the project. > > > > > > We make incompatible changes in every release; see the release notes. > > > Unless somebody can give a plausible use-case where this'd be a > > > difficult change to deal with, I concur that we don't need to > > > deprecate it ahead of time. > > > > Since I am the only one that seems to worry, I'll shut up. You are probably > > right that it the feature won't be missed by many users. > > FWIW, though I prefer to err on the side of caution when removing features > from anything, I am struggling to remember ever having used > "promote_trigger_file" > (or "trigger_file" as it was in Pg11 and earlier); grepping my private notes > brings up a single example from ca. 2012 when I appear to have been > experimenting with replication. > > On a quick web search, a large part of the results are related to its change > to a GUC in Pg 12 and/or commented out entries in sample postgresql.conf files; > most of the rest seem to be blog articles/tutorials on setting up replication. Thanks Ian, Laurenz, Robert, Tom for the discussion. Seems like we're all set then. Sorry for delaying over trivialities, but I have a couple more comments about the documentation before committing: "The trigger_file and promote_trigger_file have been removed." was missing some words. I've also added a sentence to say which releases were involved, to make it like nearby paragraphs about other obsolete stuff. The funny thing about that "obsolete" appendix is that it's intended as a URL-preserving way to document the recovery.conf file's demise in r12. It doesn't look like the right place to document ongoing changes to recovery-related GUCs in general. In this particular case it's sort of OK because the old trigger_file GUC was indeed in recovery.conf, so it's not completely irrelevant. So maybe it's OK? Perhaps in future, in a separate commit, we could have a new appendix "Obsolete settings" that has an alphabetical list of the fallen? The main documentation of pg_promote() etc now has "The parameter <varname>promote_trigger_file</varname> has been removed" in the places where the GUC was previously mentioned. Perhaps we should just remove the mentions completely (it's somehow either too much and not enough information), but I'm OK with leaving those in for now until some better place exists for historical notes. So this is the version I will push unless someone sees anything more to tweak about the documentation.
Attachment
pgsql-hackers by date: