Re: Why dump/restore to upgrade?

On Friday 08 February 2002 12:44 am, Tom Lane wrote:
> mlw <markw(at)mohawksoft(dot)com> writes:
> > but I'd like to make a general call to arms that this (or 7.3) should be
> > the last release to require this.

> We will never make such a commitment, at least not in the foreseeable
> future.

Why?

> But to bind
> ourselves forever to the current on-disk format is sheer folly.

Certainly true. But upgradability!=bound-to-the-same-format.

> And if you have to convert the datafile format then you might as
> well dump and reload.

No. Dump - reload is folly. And it doesn't always work. And that's the
problem.

I've fought this problem a long time. Too long of a time. And it is a
problem. Unfortunately, it is a problem that is going to require some deep
thought and hackery.

I believe it should be this simple for our users:

1.) Postmaster starts, finds old files. It's OK with that.

2.) A connection starts a postgres backend. When the backend starts, it sees
the old format tree and adjusts to it as best it can -- if this means fewer
features, well, it'll just have to get over it. Send a warning down the
connection that it is in reduced functionality mode or some such.

3.) An SQL command could then be issued down the connection that would, in a
transaction-safe manner, convert the data on the disk into the newest format.
Until the magic bullet upgrade command is sent, the backend operates in a
reduced functionality mode -- maybe even read-only if necessary.

In this mode, a safer pg_dump can be executed -- how many times now have we
told people to use a newer pg_dump to dump an old version database? Just
having read-only access to the old data through the new backend would in
reality be much better than the fiasco we have now -- then we can safely
pg_dump the data, stop postmaster, initdb, start postmaster, and reload the
data.

If the conversion program is large enough to cause worry about backend bloat,
then make it standalone and not let postmaster start up on old data --
pg_upgrade on steroids.

No, this isn't a core feature. Yes, there are features that are better uses
of developer time. Sure, there is a partially working pg_upgrade utility,
for which I thank Bruce for weathering it out upon.

BUT OUR UPGRADE PROCESS STINKS.

Sorry for yelling. But this touches a raw nerve for me. My apologies if I
have offended anyone -- PostgreSQL is just too good an RDBMS to suffer from
this problem. The developers here have put too much hard work of high
quality for anyone to disparage PostgreSQL due to the lack of good solid
upgrading. And I'm not upset at any one person -- it's the program; the
process; and the users that rely on our code which cause me to be this
vehement on this subject.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11