pg_resetwal prints new OldestXID in wrong circumstances - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject pg_resetwal prints new OldestXID in wrong circumstances
Date
Msg-id 5461bc85-e684-4531-b4d2-d2e57ad18cba@iki.fi
Whole thread Raw
Responses Re: pg_resetwal prints new OldestXID in wrong circumstances
List pgsql-bugs
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

Attachment

pgsql-bugs by date:

Previous
From: BharatDB
Date:
Subject: Re: BUG #19095: Test if function exit() is used fail when linked static
Next
From: "S, Naveen Krishna (Development Engineer 3)"
Date:
Subject: Re: [EXTERNAL] Re: BUG #19114: ORDER BY ASC is tampering result when calculating distance btw vectors