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:

Previous
From: Nathan Bossart
Date:
Subject: Re: wake up logical workers after ALTER SUBSCRIPTION
Next
From: Peter Smith
Date:
Subject: Re: [DOCS] Stats views and functions not in order?