Horton

Fix handling of copy_file_range() return value

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-06-22T07:19:59Z
Lists: pgsql-hackers

Attachments

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.

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.