Re: copy_file_range is now a Linux kernel call - Mailing list pgsql-hackers

From Andres Freund
Subject Re: copy_file_range is now a Linux kernel call
Date
Msg-id 20180103035103.2emyakbbdflh7xsk@alap3.anarazel.de
Whole thread Raw
In response to copy_file_range is now a Linux kernel call  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: copy_file_range is now a Linux kernel call
List pgsql-hackers
Hi,

On 2018-01-02 22:44:04 -0500, Tom Lane wrote:
> Buildfarm member caiman just came back online after some time AWOL, and
> it's not happy.  The problem evidently is that pg_rewind's copy_file_range
> function conflicts with a recently added Linux system call:
> 
> http://man7.org/linux/man-pages/man2/copy_file_range.2.html
>
Heh, just observed the same:
http://archives.postgresql.org/message-id/20180103033425.w7jkljth3e26sduc%40alap3.anarazel.de


> Looks like we'd better rename our function.  Anybody have an idea
> more creative than "pg_copy_file_range"?

I'd rather name it pg_rewind specific, something like
rwnd_copy_file_range or such. It's not a generic range copying facility,
given the way it computes source/target file names.


> (At some point somebody might want to think about fixing this function
> so it can make use of the kernel call when available.  But that's more
> work than I care to do right now, and certainly more change than I'd want
> to back-patch.)

If so we'd probably want to do so in a more generic facility than what
pg_rewind uses. But for now it indeed seems like a bad idea to do
so. Besides the backpatch concern you mention, the functionality is also
just present in an unreleased glibc version...

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: copy_file_range is now a Linux kernel call
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] GnuTLS support