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
