On Fri, Nov 18, 2022 at 2:08 AM Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Nov 17, 2022 at 2:55 AM Simon Riggs > <simon.ri...@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
