Обсуждение: pg_resetwal prints new OldestXID in wrong circumstances
When the --oldest-transaction-id option is used, pg_resetwal doesn't print the new value like it does for other similar options. For example, if you use --next-oid and --oldest-transaction-id, only the new NextOID value is printed: > $ pg_resetwal --dry-run -D data --next-oid 10 --oldest-transaction-id 100 > Current pg_control values: > > ... > > Values to be changed: > > First log segment after reset: 000000010000000000000005 > NextOID: 10 Printing the new OldestXID value is incorrectly tied to whether the --next-transaction-id option is given, so this prints it, even though OldestXID is not being modified: > $ pg_resetwal --dry-run -D data --next-oid 10 --next-transaction-id 100 > Current pg_control values: > > ... > > > Values to be changed: > > First log segment after reset: 000000010000000000000005 > NextOID: 10 > NextXID: 100 > OldestXID: 744 > OldestXID's DB: 1 This seems to have been an oversight when the --oldest-transaction-id option was added (commit 74cf7d46a91d). Before that, OldestXID was reset when the --next-transaction-id option was given. Fix attached. Barring objections, I will commit and backpatch this. - Heikki
Вложения
Hi, On Wed, Nov 19, 2025 at 11:52:31AM +0200, Heikki Linnakangas wrote: > Printing the new OldestXID value is incorrectly tied to whether the > --next-transaction-id option is given, so this prints it, even though > OldestXID is not being modified: Nice catch! > This seems to have been an oversight when the --oldest-transaction-id option > was added (commit 74cf7d46a91d). yeah. > Before that, OldestXID was reset when the > --next-transaction-id option was given. > > Fix attached. Barring objections, I will commit and backpatch this. LGTM, thanks! Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
On 19/11/2025 12:05, Bertrand Drouvot wrote: > On Wed, Nov 19, 2025 at 11:52:31AM +0200, Heikki Linnakangas wrote: >> Printing the new OldestXID value is incorrectly tied to whether the >> --next-transaction-id option is given, so this prints it, even though >> OldestXID is not being modified: > > Nice catch! > >> This seems to have been an oversight when the --oldest-transaction-id option >> was added (commit 74cf7d46a91d). > > yeah. > >> Before that, OldestXID was reset when the >> --next-transaction-id option was given. >> >> Fix attached. Barring objections, I will commit and backpatch this. > > LGTM, thanks! Committed, thanks! - Heikki