Re: PoC: true in-place major version upgrades

On Fri, Oct 30, 2026 at 2:00 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Mon, Oct 26, 2026 at 08:29:01AM -0400, Robert Haas wrote:
> > I don't really like that conclusion, because I've always felt that
> > pg_upgrade is a pretty half-baked version of upgrade-in-place. Both
> > the rather high possibility of failures requiring manual correction
> > and also the time it takes to run are real downsides, and I would like
> > to have something better. But I suspect this proposal is not the way.
> > I do wonder if some more limited version of it might make sense.
>
> I'm a bit hesitant to chime in because I don't want to derail John's
> thread, but pg_upgrade downtime is something I've thought about and worked
> on a lot over the years. I've witnessed or at least heard about many
> attempts at $subject, and thus far I'm not convinced it's viable. Sure,

Well, I didn't get to where I am today by assuming if others failed
then it's not worth trying.

> it's just software and almost anything is possible, but in this case I
> suspect it comes with a huge amount of complexity, ongoing maintenance
> burden, and really weird trade-offs.

And yet, many DBMS's are able to do it, so any theory about how
impossibly hard it is has to explain that fact. It should be table
stakes for a DBMS that aspires to be enterprise-grade.

It is non-trivial, to be sure. And I don't claim to have all the answers yet.

> I've long wondered (and even prototyped at some point) if we can address
> the downtime problem by doing the dump and restore while the old cluster is
> running. The restore specifically contributes the majority of the
> downtime, so allowing folks to use the old cluster up until the new
> cluster's schema is ready would be a huge win. We'd need to block most
> catalog changes (except for perhaps a few crucial ones like relfrozenxid
> updates), so users wouldn't be able to run DDL commands, but that still
> seems substantially better to me than being able to run _no_ commands.
>
> Maybe that's similarly complicated and unmaintainable, but ISTM that it
> could be a good incremental step that helps minimize downtime while
> retaining most of the battle-tested infrastructure of pg_upgrade.

That might very well be a low-risk practical improvement. The
benefit/effort ratio isn't enough for me to want to work in that
direction, but I certainly wouldn't discourage anyone else from
pursuing it.

--
John Naylor
Amazon Web Services