Hacker News Reader

Comment by jeltz | Hacker News Reader

Nope, that is totally unrated. To support upgrade in place without an old version of PostgreSQL:

1. The new version of PostgreSQL would need to able to read all old catalog table formats and migrate them.

2. The new version of PostgreSQL would need to support all old versions of the parse tree to migrate views.

3. Likely a bunch of more things that I do not know of. I for example doubt it is trivial to just read an old catalog without having a fully up and running cluster which supports almost everything in that old cluster. The catalog has TOAST tables and indexes for example.

Right now 1 and 2 are implemented in pg_dump plus by having pg_dump call functions in a running old version of PostgreSQL.

View on HN

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.

Reply on news.ycombinator.com