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 <byavuz81@gmail.com>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Yingying Chen <cyy9255@gmail.com>
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 fdb57d9d061bdd5ced2ed34b646b6f52071214f8..8169483b0a4528496fecb5f957d6493eab22ed03 100644 (file)
--- 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;