Horton

Re: Fix handling of copy_file_range() return value

Nazir Bilal Yavuz <byavuz81@gmail.com>

View thread View on postgr.es
From: Nazir Bilal Yavuz <byavuz81@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-06-22T08:17:44Z
Lists: pgsql-hackers 
Hi,

On Mon, 22 Jun 2026 at 10:20, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> While checking return/error handling of file system calls, I found that
> the copy_file_range() call in pg_combinebackup has a potential problem.
> If copy_file_range() returns 0, which is a documented condition, then
> the loop never makes progress and could spin forever.
>
> The other uses of copy_file_range() in the tree are surrounded by
> different logic and don't appear to have this problem.
>
> My suggested fix is to make a return value of 0 an error.  It most
> likely indicates that the source file has an unexpected size.

You are right, that is a problem only with this use of
copy_file_range(), and your patch fixes it; LGTM.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

Commits

  1. Fix handling of copy_file_range() return value

  2. Allow using copy_file_range in write_reconstructed_file

  3. Add support for incremental backup.