Re: pg_upgrade --copy-file-range
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Thomas Munro <thomas.munro@gmail.com>,
Peter Eisentraut <peter@eisentraut.org>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>,
Michael Paquier <michael@paquier.xyz>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-03-19T15:22:46Z
Lists: pgsql-hackers
Attachments
- v20240319-0002-review-and-cleanup.patch (text/x-patch) patch v20240319-0002
- v20240319-0001-rebased-patch.patch (text/x-patch) patch v20240319-0001
Hi, I took a quick look at the remaining part adding copy_file_range to pg_combinebackup. The patch no longer applies, so I had to rebase it. Most of the issues were trivial, but I had to fix a couple missing prototypes - I added them to copy_file.h/c, mostly. 0001 is the minimal rebase + those fixes 0002 has a couple review comments in copy_file, and it also undoes a lot of unnecessary formatting changes (already pointed out by Peter a couple days ago). A couple review comments: 1) AFAIK opt_errinfo() returns pointer to the local "buf" variable. 2) I wonder if we even need opt_errinfo(). I'm not sure it actually makes anything simpler. 3) I think it'd be nice to make CopyFileMethod more consistent with transferMode in pg_upgrade.h (I mean, it seems wise to make the naming more consistent, it's probably not worth unifying this somehow). 4) I wonder how we came up with copying the files by 50 blocks, but I now realize it's been like this before this patch. I only noticed because the patch adds a comment before buffer_size calculation. 5) I dislike the renaming of copy_file_blocks to pg_copyfile. The new name is way more generic / less descriptive - it's clear it copies the file block by block (well, in chunks). pg_copyfile is pretty vague. 6) This leaves behind copy_file_copyfile, which is now unused. 7) The patch reworks how combinebackup deals with alternative copy implementations - instead of setting strategy_implementation and calling that, the decisions now happen in pg_copyfile_offload with a lot of conditions / ifdef / defined ... I find it pretty hard to understand and reason about. I liked the strategy_implementation approach, as it forces us to keep each method in a separate function. Perhaps there's a reason why that doesn't work for copy_file_range? But in that case this needs much clearer comments. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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