It is a PITA, but I've written scripts that pg_dump just the schema, load the schema into the new db with the new version, set up logical replication between the two, wait for them to sync, reset all the sequences, and rebuild indexes before doing the handover.

It works with basically no downtime but I agree this kind of thing should definitely be easier, even turnkey.

I feel that really should be included in core, yes.

I get why it wasn't, but logical replication has been production ready for a while now, so it really should have at least a little sugar.

>should have at least a little sugar.

I think that sums up PG pretty well. It seems there's a lot of things that lean into it the Unix "just use another tool" philosophy that ends up making management more difficult.

Does pg_upgrade not do all that?

Or do you mean the new Pg server should transparently do the upgrade automatically? And while online?

Yes, and it does it by starting an instance of the old version and runs pg_dump against it. And that was one thing the original poster complained about.

Are pg_upgrade's docs inaccurate?

It says it works "without the data dump/restore" and...

> Major PostgreSQL releases regularly add new features that often change the layout of the system tables, but the internal data storage format rarely changes. pg_upgrade uses this fact to perform rapid upgrades by creating new system tables and simply reusing the old user data files

Regardless, I suppose it is that reliance on the unchanging of the internal data format which is limiting what refactors can do.