Re: Reducing power consumption on idle servers - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Reducing power consumption on idle servers |
Date | |
Msg-id | CA+Tgmob7ataJZSDK5Zwp_wxEiM10YakDxUBmw4=Fdtx3eZBHjg@mail.gmail.com Whole thread Raw |
In response to | Re: Reducing power consumption on idle servers (Laurenz Albe <laurenz.albe@cybertec.at>) |
Responses |
Re: Reducing power consumption on idle servers
|
List | pgsql-hackers |
On Mon, Nov 21, 2022 at 3:40 AM Laurenz Albe <laurenz.albe@cybertec.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
pgsql-hackers by date: