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

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: 达劳里亚斯 <ihaveabigdoor(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgrade --copy-file-range fails with EINVAL on Linux 4.19
Date: 2026-08-21 11:00:57
Message-ID: CAKZiRmxo17tgE1qxGfUDw0xXsHLuMrKfNJinTsqfK1N+pgiRiQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-08-21 11:01:25 Re: toast table corrupted by vacuum - missing chunk number 0 for toast value
Previous Message Matthias van de Meent 2026-08-21 10:58:36 Re: ProcArrayAdd/ProcArrayRemove in Prepared Transaction