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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
