Alvaro Herrera <alvherre@atentus.com> writes:
> Maybe there is some way of making the life easier for the upgrader.
> Let's see, when you upgrade there are basically two things that change:
> a) system catalogs
> b) on-disk representation of user data
> [much snipped]
Yup. I see nothing wrong with the pg_upgrade process that we've
previously used for updating the system catalogs, however. Trying to
do it internally in some way will be harder and more dangerous (ie,
much less reliable) than relying on schema-only dump and restore
followed by moving the physical data.
Updates that change the on-disk representation of user data are much
harder, as you say. But I think they can be made pretty infrequent.
We've only had two such updates that I know of in Postgres' history:
adding WAL in 7.1 forced some additions to page headers, and now in
7.3 we've changed tuple headers for space-saving reasons, and fixed
some problems with alignment in array data.
pg_upgrade could have worked for the 7.2 cycle, but it wasn't done,
mostly for lack of effort.
Going forward I think we should try to maintain compatibility of on-disk
user data and ensure that pg_upgrade works.
regards, tom lane
