]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
Fix handling of copy_file_range() return value
authorPeter Eisentraut <peter@eisentraut.org>
Mon, 29 Jun 2026 09:49:11 +0000 (11:49 +0200)
committerPeter Eisentraut <peter@eisentraut.org>
Mon, 29 Jun 2026 11:01:57 +0000 (13:01 +0200)
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

src/bin/pg_combinebackup/reconstruct.c

index 38d8e8a2dc9aff4b0549ec9088e9e66b396eb6cd..682028fb59eb195c9c95cb88e89fbfee821bfc7c 100644 (file)
@@ -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;