Re: optimize file transfer in pg_upgrade
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2025-03-05T20:12:44Z
Lists: pgsql-hackers
On Wed, Mar 5, 2025 at 2:42 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > Of course, rollback would still be possible, but you'd really need to > understand what "swap" mode does behind the scenes to do so safely. In any > case, I'm growing skeptical that a probably-not-super-well-tested script > that extremely few people will need and fewer will use is worth the > complexity. I don't have a super-strong view on what the right thing to do is here, but I'm definitely in favor of not doing something half-baked. If you think the revert script is going to suck, then let's not have it at all and just be clear about what the requirements for using this mode are. One serious danger that you didn't mention here is that, if pg_upgrade does fail, you may well try several times. And if you forget the revert script at some point, or run it more than once, or run the wrong version, you will be in trouble. I feel like this is something someone could very easily mess up even if in theory it works perfectly. Upgrades are often stressful times. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
initdb: Add --no-sync-data-files.
- cf131fa94285 18.0 landed
-
pg_dump: Add --sequence-data.
- 9c49f0e8cd7d 18.0 landed
-
pg_upgrade: Add --swap for faster file transfer.
- 626d7236b65d 18.0 landed
-
Add test for pg_upgrade file transfer modes.
- af0d4901c1c3 18.0 landed
-
Fix an intermetant BF failure in 003_logical_slots.
- 6f97ef05d62a 17.0 cited