Skip site navigation (1) Skip section navigation (2)

Re: Upgrading rant.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)tm(dot)ee>,mlw <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Upgrading rant.
Date: 2003-01-04 01:36:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
OK, taking up the pg_upgrade banner, I think there are two things
missing from the current code:

1) schema awareness  -- easily fixed with some code
2) need to creat clog files to match incremented xid

I can do 1, and I think Tom can help me with 2.  Then folks can test it
and see how it works.  It is that last part that made me stop around
7.2, and 7.3 had a heap format change that guarantteed it wouldn't work.
Also, I think we make index format changes more frequently that Tom
recollects.  Tom?


Lamar Owen wrote:
> On Friday 03 January 2003 18:31, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > There isn't any fundamental reason why we cannot have a pg_upgrade
> > > utility; claiming that there is something wrong with how we handle
> > > catalog changes misses the point.  The point is that *someone would
> > > have to do the work*.  Unless someone wants to step up and volunteer,
> > > there's little value in discussing it.
> > pg_upgrade does work, assuming there are no changes to the index or heap
> > file formats.  (However, I now need to update it for schemas.)  However,
> > the last time I worked on it for 7.2, no one was really interested in
> > testing it, so it never got done.  In fact, there was a bug in the
> > handling of clog or wal files, but I didn't find out about it until long
> > after 7.2 because no one was using it.
> > Is pg_upgrade too hard to run?  Is no one really interested in it?
> It has been considered 'experimental' in the past, Bruce.  It needs more 
> credibility from the development group, as in 'We recommend you try to use 
> pg_upgrade (after making a backup), then attempt to do a dump/restore if 
> pg_upgrade doesn't work" (and pg_upgrade needs to be more robust in its 
> failure modes).
> I am very interested in pg_upgrade, as I believe I mentioned the last go 
> through this topic.  But it's the 'red-headed stepchild' utility here. (I'm 
> red-headed, my mother's red-headed, so no slight meant to those of fiery 
> folicles.)  But it's also all or nothing -- you go the whole way through.
> It's again our tremendous dependence upon the contents of the system catalogs 
> that does us in.  That is one of our greatest strengths, until you have to 
> upgrade for some reason.  Then it becomes our biggest liability.
> And unlike Tom I think it is worthwhile to discuss it periodically, to remind 
> the group as a whole (which composition and membership changes frequently) 
> that there's a problem waiting to be solved.
> -- 
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2003-01-04 01:47:14
Subject: Re: Upgrading rant.
Previous:From: Tom LaneDate: 2003-01-04 01:34:02
Subject: Re: Threads

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group