Re: 7.1 Release Date

Tom Lane wrote:

> Migration tools might ease the pain, sure (though I'd still recommend
> doing a full backup before a major version upgrade, just on safety
> grounds; so the savings afforded by a tool might not be all that much).

What is needed, IMHO, is a replacement to the pg_upgrade script that can
do the following:
1.) Read _any_ previous version's format data files;
2.) Write the current version's data files (without a running
postmaster).

This replacement (call it pg_upgrade to confuse everybody) would be
called as: pg_upgrade OLDPGDATA NEWPGDATA and would simply Do The Right
Thing for that directory -- including making an ACSII dump (command line
switch, perhaps), checking disk space, robust error detection, and
_seamless_ upgrading of system catalogs and indices (all it needs to do
is call initdb on the NEWPGDATA tree, right?). The key is seamless.
The second key is _without_ a running postmaster. Much of pg_dump's
code would be needed as well, to generate an ASCII dump.

Now, this new pg_upgrade would have to know a great deal about data file
formats (but, of course, since we're on CVS, getting the old code to do
the old formats is as simple as checking out the old version, right?).

HOWEVER, I see no two ways around the fact that a core developer needs
to be the one to do this utility. In particular, the developer to write
this utility needs to know the backend code as well or better than any
other developer -- and, Tom, that person sounds like you.

Now, it _may_ be possible for another developer to do this -- and, if I
thought my grasp of the backend was good enough I would go ahead and
volunteer -- in fact, if I can get the help I need to do it, and the
time to do it in, I _will_ volunteer. Of course, it will take me much
longer to make a working tool, as I'm going to have to learn what Tom
(and others) already know -- but I am willing to put in the time to make
this work _right_. This upgrade issue has been a thorn in my side far
too long.

And, to answer the questions: currently, the RPM's have to upgrade the
way they do due to the fact that they are called during an OS upgrade
cycle -- if you are running RedHat 6.2 with the 6.5.3-6 PostgreSQL RPM's
installed, and you upgrade to Pinstripe (the RH 7 public beta), which
give you 7.0.2 RPM's, the binaries necessary to extract the data from
PGDATA are going to be wiped away by the upgrade -- currently, they are
being backed up by the RPM's pre-install script so that an upgrade
script can then call them into service after the hapless user has
figured out that PostgreSQL doesn't upgrade smoothly. This is fine and
good as long as Pinstripe can run the old binaries -- which might not be
true for the next dot-oh RedHat upgrade!

Actually, that is true _now_ is a RedHat 4.x user attempts to upgrade to
Pinstripe -- correct me if I'm wrong, Trond.

We NEED this 'pg_upgrade'-on-steroids program that simply Does The Right
Thing. Furthermore, with a little work, this program could be used to
salvage broken databases. But imagine upgrading from Postgres95 1.01 to
PostgreSQL 7.1.0 with a single pg_upgrade command AFTER loading 7.1.0
(besides, there's many bugs in pre-6.3 pg_dump, right? A dump/restore
won't work there anyway). Imagine a simple upgrade for those folks who
use large objects. It should be doable.

Note that ANY RPM-based distribution is going to have this same
problem. Yes, Tom, the RPM-based OS's upgrade procedures are
brain-dead. But, it can also be argued that our dump/restore upgrade
procedure is also brain-dead.

I think it's high time that the dump/initdb/restore cycle needs to be
retired as a normal upgrading step.

Or, to put it into 'fighting words', 'mysql doesn't have this problem.'

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11