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.


(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.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

Reply via email to