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
renamedto 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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
