Re: PoC: true in-place major version upgrades

On Fri, Oct 30, 2026 at 12:02 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Oct 28, 2026 at 9:55 AM John Naylor <johncnaylorls(at)gmail(dot)com> wrote:

> Yeah, I think most of the time it is, but I suspect it will take only
> a few nasty counterexamples to ruin your day. If you can make this
> work with every catalog change we've had in the last, idk, 7 years,
> then maybe it's worth considering, but I have a feeling that there are
> going to be some where it's pretty unpleasant. I'm willing to be
> proven wrong.

The last 7 years of change has a variety of different problems, so
it's a good demo to do. As you say, though, the past does not
guarantee the future.

> > For complex cases like that, you'd have to have a separate step when
> > the system is fully running, and that's after the main row-by-row
> > catalog migration has completed (i.e. the merge with the new binary's
> > bootstrap data) and after the node trees have been updated. So you can
> > allocate OIDs and call ChooseConstraintName() etc. So, it'd be a pain
> > in the rear at times, but I don't think it's going to be the same
> > level of sadness that some of our users encounter with pg_upgrade.
>
> I think this only works if you can guarantee that this extra step
> succeeds. Otherwise you'd have to roll back after starting the new
> system.

Okay, here's an idea, continuing with the not-null constraint example:
The old way up to version N is a v1 constraint. The N+1 release that
introduces the v2 constraint must still recognize the v1 constraint,
but all new constraints will be created as v2 constraints. A future
release, at least N+2, can drop support for v1 constraints. When the
user tries to upgrade off of N+1, the check step complains "The system
still has v1 constraints. These must be converted to v2 constraints",
and we would have some documented method to do that. This way, complex
conversions steps don't need to be happen during an already stressful
downtime window and in this case can probably just be DROP and CREATE
statements. It has a downside that it puts more responsibility on the
user, not to mention the development window with excess complexity,
but it would be less risky if complex transforms are not done
on-the-fly.

--
John Naylor
Amazon Web Services