Re: [HACKERS] PG_UPGRADE status? - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: [HACKERS] PG_UPGRADE status?
Date
Msg-id 37D6E08F.34A1559E@wgcr.org
Whole thread Raw
In response to Re: [HACKERS] PG_UPGRADE status?  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] PG_UPGRADE status?
List 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


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: [HACKERS] PG_UPGRADE status?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] PG_UPGRADE status?