On Fri, Nov 18, 2022 at 2:08 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Nov 17, 2022 at 2:55 AM Simon Riggs
> <simon.riggs@enterprisedb.com> wrote:
> > No, it will have a direct effect only on people using promote_trigger_file
> > who do not read and act upon the deprecation notice before upgrading
> > by making a one line change to their failover scripts.
>
> TBH, I wonder if we shouldn't just nuke promote_trigger_file.
> pg_promote was added in 2018, and pg_ctl promote was added in 2011. So
> even if we haven't said promote_trigger_file was deprecated, it hasn't
> been the state-of-the-art way of doing this in a really long time. If
> we think that there are still a lot of people using it, or if popular
> tools are relying on it, then perhaps a deprecation period is
> warranted anyway. But I think we should at least consider the
> possibility that it's OK to just get rid of it right away.
I agree with Robert here. It's better to do away with
promote_trigger_file, at least that's better than deprecating it now
and removing it somewhere in later releases. However, I'm a bit
worried about how it'll affect the tools/providers/extensions that
depend on it. And it turns out that this worry exists for every
feature that one thinks to get rid of.
If we go the route of doing away with promote_trigger_file, I think we
need to discuss it in a separate thread as the subject of this thread
doesn't match with what we're discussing here. This way, we'll get
thoughts from other hackers.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
