Re: unite recovery.conf and postgresql.conf

On Tue, Sep 20, 2011 at 5:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> I sympathise with this view, to an extent.
>
>> If people want to put all parameters in one file, they can do so. So +1 to that.
>
>> Should they be forced to adopt that new capability by us deliberately
>> breaking their existing setups? No. So -1 to that.
>
>> If we do an automatic include of recovery.conf first, then follow by
>> reading postgresql,conf then we will preserve the old as well as
>> allowing the new.
>
> I don't buy this argument at all.  I don't believe that recovery.conf is
> part of anyone's automated processes at all, let alone to an extent that
> they won't be able to cope with a change to rationalize the file layout.

There are many. Tools I can name include pgpool, 2warm, PITRtools, but
there are also various tools from Sun, an IBM reseller I have
forgotten the name of, OmniTI and various other backup software
providers. Those are just the ones I can recall quickly. We've
encouraged people to write software on top and they have done so.

Breaking backwards compatibility isn't something we do elsewhere, when
its easy to keep it.

I don't object to new functionality (and agreed to it upthread), just
don't break the old way when there is no need.

> And most especially I don't buy that someone who does want to keep using
> it couldn't cope with adding an "include" to postgresql.conf manually.

This just creates a barrier to upgrade. Most people using PostgreSQL
use multiple releases, so its a pain to have to maintain multiple
versions of scripts to have things work properly. Even people that
don't mind changing won't be able to do it fully. That creates
confusion, which leads to mistakes.

These things relate to backup and recovery. Any changes to them give
risk of data loss. Cosmetic considerations are secondary.

There is no command to safely confirm that "include recovery.conf" is
added to postgresql.conf, so leaving it optional makes it unclear as
to whether the old ways will work or not.

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