Re: optimize file transfer in pg_upgrade
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-11-19T03:34:00Z
Lists: pgsql-hackers
On Wed, Nov 6, 2024 at 04:07:35PM -0600, Nathan Bossart wrote: > For clusters with many relations, the file transfer step of pg_upgrade can > take the longest. This step clones, copies, or links the user relation > files from the older cluster to the new cluster, so the amount of time it > takes is closely related to the number of relations. However, since v15, > we've preserved the relfilenodes during pg_upgrade, which means that all of > these user relation files will have the same name. Therefore, it can be > much faster to instead move the entire data directory from the old cluster > to the new cluster and to then swap the catalog relation files. That is certainly a creative idea. I am surprised the links take so long. Obviously rollback would be hard, as you mentioned, while now you can rollback --link until you start. I think it clearly should be considered. The patch is smaller than I expected. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"
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