Bruce Momjian wrote:
>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?
>
>
>
As far as I've seen, it is a cool idea, but I can't trust it.
I have the USA tiger census data in a database, it is over 60G with
indexes, 30G+ of just data. Do you know how long that will take to dump
and restore? Making one index on some of the tables takes 20 minutes.
IMHO:
(1) The PostgreSQL core development team has to commit to an in place
upgrade.
I think the in-place upgrade strategy is very important, and it will
take an effort and commitment from the core development team. I doubt
seriously it can be done in a robust and safe way if the feature is not
a stated design goal.
(2) Upgrade HAS HAS HAS to be fool proof.
No one is going to use it if you say, backup your data just in case. It
should be as trust worthy as postgresql itself. If it can't be that it
is not a valid tool. Anything less will not be used by professionals and
wouldn't be worth the effort.
(3) It should be able to span more than one version.
If I upgrade from two versions back, it should work. It should not balk.
The above is simply my opinion, and probably not possible with previous
versions, but moving forward, it should be, if it is a priority. If it
is not a priority, then it is not worth doing.
Again, just my opinion.
