Re: Reducing power consumption on idle servers

On Mon, Nov 21, 2022 at 3:40 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> We have had a deprecation period? I looked at the documentation, but found
> no mention of a deprecation. How hard can it be to leave the GUC and only
> poll for the existence of the file if it is set?
>
> I personally don't need the GUC, and I know nobody who does, but I think
> we should not be cavalier about introducing unnecessary compatibility breaks.

As a project, we have a problem with deprecation warnings, simply
because community consensus changes over time as people change their
minds and as participants come and go. Slapping a deprecation notice
on things saying that they will be removed in five years does not mean
they will actually get removed in five years, nor does the failure to
slap a deprecation notice on them mean that they won't be removed in
five years. We have some instances of following through on such
promises, but plenty where what we said we were going to do and what
we actually did were quite different. Furthermore, even if we were
100% on follow-through on such things, I have no faith in the idea
that a mandatory five-year deprecation period in all cases would be
good for the project.

I think it's totally reasonable to phase out a little-used feature
that no one really cares about faster than a feature that is
heavily-relied upon and for which there are no reasonable
alternatives. Something like standard_conforming_strings or the switch
from md5 to SCRAM authentication affects not only database users but
also drivers and applications; time needs to be allowed for the effect
to seep through the whole ecosystem. Backward compatibility is really
important for the transition period. In this case, though, the
alternatives have already existed for a long time and we have reasons
to think most people have already been using them for a long time.
Moreover, if they haven't been, the transition shouldn't be too hard.
For there to be a problem here, we have to imagine a user who not
can't run pg_promote() or pg_ctl promote, who can only create a file,
and who furthermore needs that file to be located someplace other than
the data directory. I'm having a hard time envisioning that.

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.

P.S. One notable example of how bad we are at these things is that
contrib/xml2 has been deprecated since PostgreSQL 8.3. The deprecation
notice says that it isn't needed any more because all of the
functionality is otherwise available, but some people think that's not
true so we haven't removed the module. An obvious alternative would be
to remove the deprecation notice but FWICT other people think that
getting rid of it is the right idea so we haven't done that either.
Whee.

--
Robert Haas
EDB: http://www.enterprisedb.com