Re: Reducing power consumption on idle servers
От | Laurenz Albe |
---|---|
Тема | Re: Reducing power consumption on idle servers |
Дата | |
Msg-id | a36e97bf52f242ef130199ed99a50b9026149684.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Reducing power consumption on idle servers (Simon Riggs <simon.riggs@enterprisedb.com>) |
Ответы |
Re: Reducing power consumption on idle servers
Re: Reducing power consumption on idle servers |
Список | pgsql-hackers |
On Mon, 2022-11-21 at 07:36 +0000, Simon Riggs wrote: > On Mon, 21 Nov 2022 at 05:07, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > > > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote: > > > I'll wait 24 hours before committing, to > > > provide a last chance for anyone who wants to complain about dropping > > > promote_trigger_file. > > > > Remove "promote_trigger_file"? Now I have never seen anybody use that > > parameter, but I don't think that it is a good idea to deviate from our > > usual standard of deprecating a feature for about five years before > > actually removing it. > > We aren't removing the ability to promote, just enforcing a change to > a better mechanism, hence I don't see a reason for a long(er) > deprecation period than we have already had. 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. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: