From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Incorrect version number given to sync_pgdata() in pg_combinebackup.c |
Date: | 2025-10-10 06:21:25 |
Message-ID: | aOil5d0y87ZM_wsZ@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
pg_combinebackup-version.patch | text/x-diff | 507 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Shubham Khanna | 2025-10-10 06:26:20 | Re: Add support for specifying tables in pg_createsubscriber. |
Previous Message | Michael Paquier | 2025-10-10 06:07:42 | Re: Executing pg_createsubscriber with a non-compatible control file |