Re: [HACKERS] PG_UPGRADE status?

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] PG_UPGRADE status?
Date: 1999-09-08 22:17:52
Message-ID: 37D6E08F.34A1559E@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
> Lamar Owen wrote:
> > For normal situations, it is. However, in an RPM upgrade that occurs as
> > part of an OS upgrade (say, from RedHat 6.0 to RedHat 6.1), NO daemons
> > can be run during a package upgrade. That doesn't seem too bad until you
> > realize just what an RPM upgrade does....
>
> Wow, doing a database upgrade inside an automated RPM. That's quite a
> task. From your description, running pg_dumpall and psql to load the
> data is a real chore in an automated system.

Oliver Elphik has done this for the Debian packages -- but debs don't
have some of the draconian restrictions RPM's do. In particular, and
RPM that is packaged in the Official Boxed Set CANNOT under any
circumstances ask for input from the user, nor can it output anything to
the user. RPM's that do so get kicked out of the boxed set. And,
frankly, PostgreSQL's position in the boxed set is a Big Win.

> Considering the changes in aligment of row elements, and index table
> changes, it would be quite difficult to write a program to convert that
> data from one format to another. Not impossible, but quite hard.

Reference my message to Tom Lane. Yes, such a program would be hard --
but most of it is already written and available in CVS -- thank God for
CVS! -- all that's needed is to extract the storage managers for each
major version, extract the reading code, etc, to get the on-disk
representation to an intermediate in memory form, then write it out with
the latest and greatest storage manager (into a different file, of
course, until the upgrade is finished). Unless I badly misunderstand
the way PostgreSQL does things, that should work -- but I may not have
expressed it the same way I see it in my mind.

I'm talking about a stripped down backend, in essence, whose only
purpose in life is to copy in and copy out -- but who has the unique
ability to read with one storage manager and write with another. You
simply choose which storge manager is used for reading by the version of
the PGDATA tree.

Piecing together the right CVS code snippets will be a challenge.

Lamar Owen
WGCR Internet Radio

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-09-08 22:22:49 Re: [HACKERS] PG_UPGRADE status?
Previous Message Lamar Owen 1999-09-08 22:07:09 Re: [HACKERS] PG_UPGRADE status?