Folks, We have a problem.
With all due respect to the valiant efforts of people over the years who have tried to make an upgrade-in-place system work, I would like to note that such a system faces what I believe are insurmountable barriers to being done correctly. I will then propose an alternative. We have seen each one of the following on multiple occasions: - It's extraordinarily unglamorous work. This further restricts the already tiny pool of people who might work on it. If somebody has a sustainable way to increase the glamour, that might help, but... - To do correctly, it requires broad and intimate knowledge of the storage system and the systems below it (what is and isn't actually invariant across filesystems and kernels, e.g.) at a level that even most core engine hackers do not possess. - It's always done under extreme time pressure, namely between feature freeze (more properly, all-other-code-freeze, if it's to be actually correct) and release. We haven't even attempted the "properly" version for what I hope are pretty obvious reasons. - It's extraordinarily difficult to test even normal cases, let alone corner cases, especially in light of the time pressure. - Failure modes tend to be silent (or at least whispering) data corruption, not infrequently permanent. That all sounds grim because it is. HOWEVER All is not lost. We can relax the in-place requirement because of the economics of computing. The components of a node have been getting drastically cheaper for decades while (amazingly, if you think about it) increasing in quality. Rented ("cloud") nodes have gotten steadily cheaper and better, too, although not over quite as long a haul. In light of the above, it is perfectly reasonable to require, at least temporarily, setting up duplicate storage, or another node. I am aware that some cases exist where this is not possible, but I don't think we should twist ourselves into pretzels to accommodate a tiny minority of our users, which my experience in the field leads me to believe is the case. As a relatively (to our users) minor course correction, I would like to propose the following: - Keep the current pg_upgrade code, but put loud deprecation warnings all over it, most emphatically all over its documentation. - Develop a logical upgrade path as a part of the (Yay! Sexy!) logical replication that's already in large part built. This path would, of course, run either locally or across a network, and be testable in both cases. There would be a downgrade path, namely switching origin nodes. What say? Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers