Re: PoC: true in-place major version upgrades

On Wed, Oct 28, 2026 at 9:55 AM John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
> > every major release would need a matching pg_upgrade patch to teach it
> > about all the transformations that are required, and when they should
> > error out,
>
> Most of the time, it's just going to be new columns containing '0' or
> 'null', isn't it? But maybe I'm missing something, but it seems to me
> that most catalogs' form or semantics don't change all that much. As I
> mentioned to Tom, the only upgrade that the prototype tried with the
> (almost) full regression database was 18 -> 20devel.

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.

> 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.

--
Robert Haas
Databricks