A Modest Upgrade Proposal

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.
Ifsomebody 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'tactually 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'sto be actually correct) and release.  We haven't even attempted the "properly" version for what I hope are pretty
obviousreasons.
 

- 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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate