Re: pg_upgrade --copy-file-range

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>, Thomas Munro <thomas.munro@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-03-25T14:31:00Z
Lists: pgsql-hackers
On Sat, Mar 23, 2024 at 9:37 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> OK, that makes sense. Here's a patch that should work like this - in
> copy_file we check if we need to calculate checksums, and either use the
> requested copy method, or fall back to the block-by-block copy.

+        Use efficient file cloning (also known as <quote>reflinks</quote> on
+        some systems) instead of copying files to the new cluster.  This can

new cluster -> output directory

I think your version kind of messes up the debug logging. In my
version, every call to copy_file() would emit either "would copy
\"%s\" to \"%s\" using strategy %s" and "copying \"%s\" to \"%s\"
using strategy %s". In your version, the dry_run mode emits a string
similar to the former, but creates separate translatable strings for
each copy method instead of using the same one with a different value
of %s. In non-dry-run mode, I think your version loses the debug
logging altogether.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

  1. Allow using copy_file_range in write_reconstructed_file

  2. Allow copying files using clone/copy_file_range

  3. Align blocks in incremental backups to BLCKSZ

  4. Add --copy-file-range option to pg_upgrade.