| 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.
| 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 |