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.


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?

David Fetter <>
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP:

Remember to vote!
Consider donating to Postgres:

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to