Hi all,

While hacking on a different thing that touched pg_combinebackup, I
have bumped into a silly bug.

To keep it short, the version number is calculated based on this code
in read_pg_version_file(), where "version" is the result of strtoul() 
applied to the contents of PG_VERSION:
    return version * 10000;

For v18, this would return 180000, which is fine.

A bit later on, we do that, which is not fine:
    sync_pgdata(opt.output, version * 10000, opt.sync_method, true);

This leads to a version number higher than expected, multiplied twice.
This was harmless, because sync_pgdata uses the version number to make
the difference between pg_wal/ and pg_xlog/, and pg_combinebackup does
not support versions older than v10, which is exactly where the
renamed happened.  Hence, even if the version number was too high, we
always expect to flush pg_wal/.

Trivial patch attached, for a backpatch down to where pg_combinebackup
has been introduced.

Thoughts?
--
Michael
diff --git a/src/bin/pg_combinebackup/pg_combinebackup.c b/src/bin/pg_combinebackup/pg_combinebackup.c
index f5cef99f6273..a330c09d939d 100644
--- a/src/bin/pg_combinebackup/pg_combinebackup.c
+++ b/src/bin/pg_combinebackup/pg_combinebackup.c
@@ -425,7 +425,7 @@ main(int argc, char *argv[])
 		else
 		{
 			pg_log_debug("recursively fsyncing \"%s\"", opt.output);
-			sync_pgdata(opt.output, version * 10000, opt.sync_method, true);
+			sync_pgdata(opt.output, version, opt.sync_method, true);
 		}
 	}
 

Attachment: signature.asc
Description: PGP signature

Reply via email to