Content-Type: multipart/mixed; boundary="------------kO0561aOu9CcDpLDz8T2Elgq"
Message-ID: <5461bc85-e684-4531-b4d2-d2e57ad18cba@iki.fi>
Date: Wed, 19 Nov 2025 11:52:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
Subject: pg_resetwal prints new OldestXID in wrong circumstances
To: "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/5461bc85-e684-4531-b4d2-d2e57ad18cba%40iki.fi>
Precedence: bulk

This is a multi-part message in MIME format.
--------------kO0561aOu9CcDpLDz8T2Elgq
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------kO0561aOu9CcDpLDz8T2Elgq
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-Print-new-OldestXID-value-in-pg_resetwal-when-it-s-b.patch"
Content-Disposition: attachment;
 filename*0="0001-Print-new-OldestXID-value-in-pg_resetwal-when-it-s-b.pa";
 filename*1="tch"
Content-Transfer-Encoding: base64

RnJvbSA0M2MwZDI2ODUyZjlmZDFiMGM3ZjBiMjc0YWNiNzJiYzY5ODU0MTRmIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBIZWlra2kgTGlubmFrYW5nYXMgPGhlaWtraS5saW5u
YWthbmdhc0Bpa2kuZmk+CkRhdGU6IFdlZCwgMTkgTm92IDIwMjUgMTE6NDg6MzAgKzAyMDAK
U3ViamVjdDogW1BBVENIIDEvMV0gUHJpbnQgbmV3IE9sZGVzdFhJRCB2YWx1ZSBpbiBwZ19y
ZXNldHdhbCB3aGVuIGl0J3MgYmVpbmcKIGNoYW5nZWQKCkNvbW1pdCA3NGNmN2Q0NmE5MWQg
YWRkZWQgdGhlIC0tb2xkZXN0LXRyYW5zYWN0aW9uLWlkIG9wdGlvbiB0bwpwZ19yZXNldHdh
bCwgYnV0IGZvcmdvdCB0byB1cGRhdGUgdGhlIGNvZGUgdGhhdCBwcmludHMgYWxsIHRoZSBu
ZXcKdmFsdWVzIHRoYXQgYXJlIGJlaW5nIHNldC4gRml4IHRoYXQuCgpEaXNjdXNzaW9uOiBY
WFgKQmFja3BhdGNoLXRocm91Z2g6IDE0Ci0tLQogc3JjL2Jpbi9wZ19yZXNldHdhbC9wZ19y
ZXNldHdhbC5jIHwgNCArKysrCiAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspCgpk
aWZmIC0tZ2l0IGEvc3JjL2Jpbi9wZ19yZXNldHdhbC9wZ19yZXNldHdhbC5jIGIvc3JjL2Jp
bi9wZ19yZXNldHdhbC9wZ19yZXNldHdhbC5jCmluZGV4IGEzMWU3NjQzY2YwLi44ZDVkOTgw
NTI3OSAxMDA2NDQKLS0tIGEvc3JjL2Jpbi9wZ19yZXNldHdhbC9wZ19yZXNldHdhbC5jCisr
KyBiL3NyYy9iaW4vcGdfcmVzZXR3YWwvcGdfcmVzZXR3YWwuYwpAQCAtODM5LDYgKzgzOSwx
MCBAQCBQcmludE5ld0NvbnRyb2xWYWx1ZXModm9pZCkKIAl7CiAJCXByaW50ZihfKCJOZXh0
WElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICV1XG4iKSwKIAkJCSAgIFhpZEZy
b21GdWxsVHJhbnNhY3Rpb25JZChDb250cm9sRmlsZS5jaGVja1BvaW50Q29weS5uZXh0WGlk
KSk7CisJfQorCisJaWYgKHNldF9vbGRlc3RfeGlkICE9IDApCisJewogCQlwcmludGYoXygi
T2xkZXN0WElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAldVxuIiksCiAJCQkgICBD
b250cm9sRmlsZS5jaGVja1BvaW50Q29weS5vbGRlc3RYaWQpOwogCQlwcmludGYoXygiT2xk
ZXN0WElEJ3MgREI6ICAgICAgICAgICAgICAgICAgICAgICAldVxuIiksCi0tIAoyLjQ3LjMK
Cg==

--------------kO0561aOu9CcDpLDz8T2Elgq--