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

  1. initdb: Add --no-sync-data-files.

  2. pg_dump: Add --sequence-data.

  3. pg_upgrade: Add --swap for faster file transfer.

  4. Add test for pg_upgrade file transfer modes.

  5. Fix an intermetant BF failure in 003_logical_slots.