=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= <jltal...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
