> 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
* 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.

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to