On Tue, Sep 20, 2011 at 5:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
