Re: unite recovery.conf and postgresql.conf

On Tue, Sep 27, 2011 at 10:34 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Sep 26, 2011 at 7:45 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On sön, 2011-09-25 at 12:58 -0400, Tom Lane wrote:
>>> And it's not like we don't break configuration file
>>> contents in most releases anyway, so I really fail to see why this one
>>> has suddenly become sacrosanct.
>>
>> Well, there is a slight difference.  Changes in postgresql.conf
>> parameter names and settings are adjusted automatically for me by my
>> package upgrade script.  If we, say, changed the names of recovery.conf
>> parameters, I'd have to get a new version of my $SuperReplicationTool.
>> That tool could presumably look at PG_VERSION and put a recovery.conf
>> with the right spellings in the right place.
>>
>> But if we completely change the way the replication configuration
>> interacts, it's not clear that a smooth upgrade is possible without
>> significant effort.  That said, I don't see why it wouldn't be possible,
>> but let's design with upgradability in mind, instead of claiming that we
>> have never supported upgrades of this kind anyway.
>
> Currently recovery.conf has two roles:
>
> #1. recovery.conf is used as a trigger file to enable archive recovery.
>      At the end of recovery, recovery.conf is renamed to recovery.done.
>
> #2. recovery.conf is used as a configuration file for recovery parameters.
>
> Which role do you think we should support in 9.2 because of the backward
> compatibility? Both? Unless I misunderstand the discussion so far, Tom and
> Robert (and I) agree to get rid of both. Simon seems to agree to remove
> only the former role, but not the latter. How about you? If you agree to
> remove the former, too, let's focus on the discussion about whether the
> latter role should be supported in 9.2.

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.

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.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services