Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format
Date
Msg-id 11245.1451489369@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format  (José Luis Tallón <jltallon@adv-solutions.net>)
List pgsql-hackers
José Luis Tallón <jltallon@adv-solutions.net> writes:
> On 12/30/2015 06:46 AM, Simon Riggs wrote:
>> There is already long precedent about how to represent an XID with an 
>> epoch... and it is neither of those two formats.

> IMHO, we have been telling users that XIDs are 32bits forever, so 
> showing a 64bits int where an XID is expected can easily induce confusion.

Yeah.  Also, if you look at xmin or xmax in any stored row, it's only
going to be 32 bits.  If we make pg_controldata merge the epoch into a
decimal representation, it's going to be a serious PITA to manually
compare stored XIDs to the printout.

We've talked about making on-disk XIDs be effectively 64 bits (with
some trick or other to avoid taking a big space hit).  If that ever
happens, and we start printing xmin/xmax as true 64-bit values, then
it'd be appropriate for pg_controldata to do the same.  But right now
I think a split format is still the way to go.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Better detail logging for password auth failures
Next
From: Evgeniy Shishkin
Date:
Subject: Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)