Re: pg_upgrade --copy-file-range fails with EINVAL on Linux 4.19

Hi Jakub,

Here is a patch for option (4): do not define HAVE_COPY_FILE_RANGE
when building against Linux kernel headers older than 5.3.

The cutoff is the build-time <linux/version.h> (LINUX_VERSION_CODE),
not uname(2). Autoconf and Meson use the same compile probe.
Non-Linux still does a plain function check. configure was
regenerated with GNU Autoconf 2.69.

I did not change the copy loop or add a fallback. --copy-file-range
remains in --help; on an unsupported build it fails with
"copy_file_range not supported on this platform".

Docs now say Linux kernel 5.3 and later
(pg_upgrade, pg_combinebackup, file_copy_method).

Tested:

Debian 10 (buster), Linux 4.19.0-27-amd64,
<linux/version.h> LINUX_VERSION_CODE 267263.
Out-of-tree Autoconf (--enable-cassert --enable-debug --enable-tap-tests):

checking whether <linux/version.h> is 5.3 or later... no
/* #undef HAVE_COPY_FILE_RANGE */

make -C src/bin/pg_upgrade check: PASS (8 files, 133 tests)
t/006_transfer_modes.pl ok
(--copy-file-range took the unsupported path:
stdout/stderr matches)
make -C src/bin/pg_combinebackup check: PASS (12 files, 120 tests)

pg_upgrade --check --copy-file-range on two empty initdb copies:

copy_file_range not supported on this platform
Failure, exiting

--help still lists --copy-file-range for pg_upgrade and
pg_combinebackup.

Meson setup (0.61.5, -Dcassert=true -Dtap_tests=enabled):
"<linux/version.h> is 5.3 or later" compiles: NO
HAVE_COPY_FILE_RANGE absent from pg_config.h
ninja 1.8.2 failed to read build.ninja (depslog), so I did not
complete a Meson compile or TAP run on this host.

Ubuntu 22.04.5 LTS (WSL2), Linux 6.6.87.2-microsoft-standard-WSL2,
<linux/version.h> 5.15.209 (LINUX_VERSION_CODE 331729).
Out-of-tree Autoconf (same flags):

checking whether <linux/version.h> is 5.3 or later... yes
checking for copy_file_range... yes
#define HAVE_COPY_FILE_RANGE 1

pg_upgrade --check --copy-file-range: *Clusters are compatible*
make -C src/bin/pg_upgrade check: PASS (8 files, 143 tests)
006 success path: test1 data after pg_upgrade --copy-file-range
make -C src/bin/pg_combinebackup check: PASS (12 files, 120 tests)

Meson (0.61.2, ninja 1.10.1, -Dcassert=true -Dtap_tests=enabled):
"<linux/version.h> is 5.3 or later" compiles: YES
#define HAVE_COPY_FILE_RANGE 1
meson test pg_upgrade/006_transfer_modes: OK (50 subtests)
meson test --suite pg_combinebackup: OK (12 tests)
pg_upgrade --check --copy-file-range: *Clusters are compatible*

--help still lists the option on both binaries.

FreeBSD was not tested.

Thanks,
Johnny

达劳里亚斯 <ihaveabigdoor(at)gmail(dot)com> 于2026年8月22日周六 18:21写道：
>
> Hi Jakub,
>
> Thanks, option (4) makes sense to me. I'll prepare a patch to disable
> HAVE_COPY_FILE_RANGE when building against Linux kernel headers older
> than 5.3, covering both the Autoconf and Meson build paths.
>
> Thanks,
> Johnny
>
> Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> 于2026年8月21日周五 19:01写道：
> >
> > Hi Johnny,
> >
> > On Fri, Aug 21, 2026 at 8:19 AM 达劳里亚斯 <ihaveabigdoor(at)gmail(dot)com> wrote:
> > >
> > [..]
> > > On 4.19 a non-empty source makes round 1 return > 0, so round 2 always
> > > runs, always returns EINVAL, and we pg_fatal.
> > > An empty file would return 0 on round 1 and skip round 2; relation
> > > files are not empty.
> >
> > As per [1], the 4.19 (LTS series) was released in 2018 and went EOS on 2024
> > and running that today anywhere on production would be not responsilbe
> > anyway, so option 4: why just not add override #undef HAVE_FILE_COPY_RANGE
> > when kernel is < 5.3 then? (in configure.ac and meson.build). Dunno what else
> > may misbehave there as nobody is going to test it combitation with that old
> > fs code too, but at least the tests won't complain. We use that syscall in
> > other tools too...
> >
> > -J.
> >
> > [1] - https://endoflife.date/linux