Re: Reducing power consumption on idle servers

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Zheng Li <zhengli10(at)gmail(dot)com>, Jim Nasby <nasbyj(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing power consumption on idle servers
Date: 2022-11-27 23:56:48
Message-ID: CA+hUKGLaDk4R95hfk044hpaomcA3tEdLddsH14dD11jWQkZ8sA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 27, 2022 at 6:15 PM Ian Lawrence Barwick <barwick(at)gmail(dot)com> wrote:
> 2022年11月22日(火) 5:50 Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>:
> > On Mon, 2022-11-21 at 12:11 -0500, Tom Lane wrote:
> > > Robert Haas <robertmhaas(at)gmail(dot)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 Content-Type Size
v12-0001-Remove-promote_trigger_file.patch text/x-patch 9.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2022-11-28 00:07:02 Re: [DOCS] Stats views and functions not in order?
Previous Message Nathan Bossart 2022-11-27 23:45:28 Re: wake up logical workers after ALTER SUBSCRIPTION