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