Josh, >> 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. > > Actually, just to correct this list: > * there are no tools from Sun > * pgPool2 does not deal with recovery.conf
I'm not sure what you mean by "not deal with" but part of pgpool-II's functionality assumes that we can easily generate recovery.conf. If reconf.conf is integrated into postgresql.conf, we need to edit postgresql.conf, which is a little bit harder than generating recovery.conf, I think. > * there are additional ones: WAL-E, etc., which may or may not need to > be edited. > >> Breaking backwards compatibility isn't something we do elsewhere, when >> its easy to keep it. > > FWIW, I've already found that I have to modify all my backup scripts for > 9.0 from 8.4, and again for 9.1 from 9.0. So we do break backwards > compatibility, frequently. > >> I don't object to new functionality (and agreed to it upthread), just >> don't break the old way when there is no need. > > I'm happy to make upgrades easier, but I want a path which eventually > ends in recovery.conf going away. It's a bad API, confuses our users, > and is difficult to support and maintain. If you think it's easier on > our users to do that in stages over several versions rather than in one > fell swoop, then let's plan it that way. > > -- > Josh Berkus > PostgreSQL Experts Inc. > http://pgexperts.com > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
