From: Peter Eisentraut Date: Mon, 29 Jun 2026 09:49:11 +0000 (+0200) Subject: Fix handling of copy_file_range() return value X-Git-Tag: REL_19_BETA2~100 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=994f770a0fd55dfdeb96d1d60d35545ba2d51480;p=thirdparty%2Fpostgresql.git Fix handling of copy_file_range() return value Treat copy_file_range() return value of zero as an error: it indicates that no bytes could be copied (perhaps the source file is shorter than expected), and the existing retry loop would otherwise spin forever since nwritten would never reach BLCKSZ. The other uses of copy_file_range() in the tree don't have this problem. Reviewed-by: Nazir Bilal Yavuz Reviewed-by: Kyotaro Horiguchi Reviewed-by: Yingying Chen Discussion: https://www.postgresql.org/message-id/flat/3208cf7a-c7f3-41eb-92f6-33cbeff4df40%40eisentraut.org --- diff --git a/src/bin/pg_combinebackup/reconstruct.c b/src/bin/pg_combinebackup/reconstruct.c index 3349aa2441d..38e756be7ef 100644 --- a/src/bin/pg_combinebackup/reconstruct.c +++ b/src/bin/pg_combinebackup/reconstruct.c @@ -705,6 +705,9 @@ write_reconstructed_file(char *input_filename, if (wb < 0) pg_fatal("error while copying file range from \"%s\" to \"%s\": %m", input_filename, output_filename); + else if (wb == 0) + pg_fatal("unexpected end of file while copying file range from \"%s\" to \"%s\"", + input_filename, output_filename); nwritten += wb;