I volunteer

[Lamar Owen]

On Saturday 27 September 2003 04:44 am, Chuck Wolber wrote:
> > I as PostgreSQL RPM maintainer for the PostgreSQL Global Development
> > Group do something similar to this using a loose group of volunteers.

> <TROLL>
> Ahhh, so you're the one. Perhaps you could write a postgreSQL RPM with
> upgrade functionality that actually works?
> </TROLL>

<TROLL feed=1, mode-nice>
Visit www.postgresql.org, find the e-mail archives for pgsql-hackers, and 
search on the string 'Upgrading rant'.

It is not possible to upgrade PostgreSQL major versions within the RPM 
framework in a robust manner (or at least I've not yet found a way).  It is 
an upstream, and not a packaging, issue.  If you have ideas to the contrary, 
subscribe to pgsql-hackers at postgresql.org and contribute your brilliance. ;-)
</TROLL>

I've been fighting that battle for over four years now, since I started 
maintaining the set in 1999 (PostgreSQL 6.5).  At first, I thought I (with 
the help of Jeff Johnson, Cristian Gafton, and the excellent beta team at 
beta.redhat.com) had the problem mostly licked.  But then the upstream 
package broke the pseudo upgrades.  Trond Eivind Glomsrød worked on it, and 
he and I finally gave up trying to do it the way we were doing it after the 
upstream broke it again.  It is a problem that really shouldn't be fixed in 
packaging, IMHO, since it isn't a problem just for RPM upgrades.

Just last week the item 
        * Allow major upgrades without dump/reload, perhaps using
          pg_upgrade
was added to TODO.  It has been a long ride getting just that much out.  Also 
search on the threads 'State of beta 2', 'need for inplace upgrading', and 
combine the terms RPM and upgrade in a search.

The short of it: PostgreSQL stores a vast amount of system configuration data 
in the system catalogs in the 'template1' database.  Stuff like functions to 
use for input and output conversions are inside the system catalogs, 
coexisting in the same database as pointers to the user's data, the user's 
functions, the user's custom types, operators, and the like.  These catalogs 
change every major release.  OID's for the functions, for types, for 
operators, etc. all change.  And then sometimes the actual page format for 
the data itself is changed -- the most recent time was between 7.2.x and 
7.3.x, but it has happened a handful of times before that.  It is a hard 
problem that people who are far smarter than I have been stumped over, or 
just not motivated to fix it.

But I'm open to ideas as to how to make it less painful.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu