Hi, Here are two small patches to improve pg_combinebackup slightly.
0001: I noticed that there is some logic in reconstruct.c that constructs a pathname of the form a/b//c instead of a/b/c. AFAICT, this still works fine; it just looks ugly. It's possible to get one of these pathnames to show up in an error message if you have a corrupted backup, e.g.: pg_combinebackup: error: could not open file "x/base/1//INCREMENTAL.6229": No such file or directory pg_combinebackup: removing output directory "xy" So 0001 fixes this. 0002: If you try to do something like pg_combinebackup incr1 incr2 -o result, you'll get an error saying that the first backup must be a full backup. This is an implementation restriction that might be good to lift, but right now that's how it is. However, if you do pg_combinebackup full incr -o result, but the full backup happens to contain an INCREMENTAL.* file that also exists in the incremental backup, then you won't get an error. Instead you'll reconstruct a completely bogus full file and write it to the result directory. Now, this should really be impossible unless you're intentionally trying to break pg_combinebackup, but it's also pretty lame, so 0002 fixes things so that you get a proper error, and also adds a test case. Review appreciated. My plan is to commit at least to master and possibly back-patch. Opinions on whether to back-patch are also appreciated. Thanks, -- Robert Haas EDB: http://www.enterprisedb.com
v1-0001-pg_combinebackup-When-reconstructing-avoid-double.patch
Description: Binary data
v1-0002-pg_combinebackup-Error-if-incremental-file-exists.patch
Description: Binary data
