Tom Lane wrote:
> The system tables are not the problem.  pg_upgrade has shown how we
> can have cross-version upgrades no matter how much the system catalogs
> change (a good thing too, because we cannot freeze the system catalog
> layout without bringing development to a standstill).  A schema-only
> dump and restore is cheap enough that there's no real reason to look
> for any other solution.
> Changes in the on-disk representation of user tables would be harder to
> deal with, but they are also much rarer (AFAIR we've only done that
> twice: WAL required additions to page and tuple headers, and then there
> were Manfred's space-saving changes in 7.3).  And as of 7.3 there is a
> version field in page headers, which would in theory allow for a
> page-at-a-time update process to work.
> 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?

  Bruce Momjian                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to