Re: Incorrect version number given to sync_pgdata() in pg_combinebackup.c
Chao Li <li.evan.chao@gmail.com>
From: Chao Li <li.evan.chao@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-10T06:39:58Z
Lists: pgsql-hackers
> On Oct 10, 2025, at 14:21, Michael Paquier <michael@paquier.xyz> wrote: > > 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 > <pg_combinebackup-version.patch> Yeah, looks like a stupid bug. read_pg_version_file() has multiplied 10000 to version number. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
Commits
-
Fix version number calculation for data folder flush in pg_combinebackup
- a7346770813e 17.7 landed
- a6598aac5295 18.1 landed
- 1c05fe11abb6 19 (unreleased) landed