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
