On Wed, Sep 20, 2006 at 09:28:42PM +1000, Gavin Sherry wrote:
>
> Well, I think that people who really want downgrade in such a tool are
> those for which slony replication is just not an option. That is, data in
> the range of hundreds of gigabytes. Using slony to upgrade is often not
> practical either.
Yes, I figured as much. I was just suggesting that people who
_really_ need the fault tolerance of being able to fall back do have
an option, though it's probably somewhat painful to use. (You can
use Slony for hundreds of gigs, although if the throughput is high
enough, it might be tricky to get started.)
> I wonder if pg_upgrade could be designed in such a way that upgrade is the
> same as downgrade from a development point of view. That is, the tool can
> change the system from one binary format to another.
I guess the question is whether there is any case where you can map
an old version of some feature into some number of more-granular new
versions, but going the other way is impossible. I know that sounds
all hand-wavy. The analogy I'm thinking of is cases I've worked on
where protocols change: the old protocol has one flag that can
happily be mapped into, say, three in the new system. But in the new
system, you can have just one of those flags by itself, and there's
no obvious way to preserve that data when moving back to the old
protocol. If we never have that sort of case with the binary
formats, then what you propose ought to work.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack. --Scott Morris