2022年11月22日(火) 5:50 Laurenz Albe <laurenz.a...@cybertec.at>: > > On Mon, 2022-11-21 at 12:11 -0500, Tom Lane wrote: > > Robert Haas <robertmh...@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. Regards Ian Barwick