Simon, > Tatsuo/Josh/Robert also discussed how recovery.conf can be used to > provide parameters solely for recovery. That is difficult to do > without causing all downstream tools to make major changes in the ways > they supply parameters.
Actually, this case is easily solved by an "include recovery.conf" parameter. So it's a non-issue. > Keeping our APIs relatively stable is important to downstream tools. I > have no objection to a brave new world, as long as you don't chuck out > the one that works right now. Breaking APIs needs a good reason and > I've not seen one discussed anywhere. No problem with immediately > deprecating the old API and declare is planned to be removed in > release 10.0. So after debugging some of our failover scripts, here's the real-world problems I'm trying to solve. These design flaws are issues which cause automated failover or failback to abort, leading to unexpected downtime, so they are not just issues of neatness: 1. Recovery.conf being both a configuration file AND a trigger to initiate recovery mode, preventing us from separating configuration management from failover. 2. The inability to read recovery.conf parameters via SQL on a hot standby, forcing us to parse the file to find out its settings, or guess. (1) is a quite serious issue; it effectively makes recovery.conf impossible to integrate with puppet and other configuration management frameworks. I also don't see a way to fix it without breaking backwards compatibility. BTW, I'm not criticizing the original design for this. We simply didn't know better until lots of people were using these tools in production. But it's time to fix them, and the longer we wait, the more painful it will be. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers