Re: pg_upgrade --copy-file-range
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-12-22T20:52:59Z
Lists: pgsql-hackers
On Sat, Dec 23, 2023 at 9:40 AM Peter Eisentraut <peter@eisentraut.org> wrote: > On 13.11.23 08:15, Peter Eisentraut wrote: > > On 08.10.23 07:15, Thomas Munro wrote: > >>> About your patch: > >>> > >>> I think you should have a "check" function called from > >>> check_new_cluster(). That check function can then also handle the "not > >>> supported" case, and you don't need to handle that in > >>> parseCommandLine(). I suggest following the clone example for these, > >>> since the issues there are very similar. > >> > >> Done. > > > > This version looks good to me. > > > > Tiny nit: You copy-and-pasted "%s/PG_VERSION.clonetest"; maybe choose a > > different suffix. > > Thomas, are you planning to proceed with this patch? Yes. Sorry for being slow... got stuck working on an imminent new version of streaming read. I will be defrosting my commit bit and committing this one and a few things shortly. As it happens I was just thinking about this particular patch because I suddenly had a strong urge to teach pg_combinebackup to use copy_file_range. I wonder if you had the same idea...
Commits
-
Allow using copy_file_range in write_reconstructed_file
- ac8110155132 17.0 landed
-
Allow copying files using clone/copy_file_range
- f8ce4ed78ca6 17.0 landed
-
Align blocks in incremental backups to BLCKSZ
- 10e3226ba13d 17.0 landed
-
Add --copy-file-range option to pg_upgrade.
- d93627bcbe50 17.0 landed